stroeer / tapir Goto Github PK
View Code? Open in Web Editor NEWT-online API Repository
Home Page: https://stroeer.github.io/tapir/article.html
License: Apache License 2.0
T-online API Repository
Home Page: https://stroeer.github.io/tapir/article.html
License: Apache License 2.0
See: bufbuild/protobuf-es#252 (comment)
Pros:
ts-protoc-gen
(dead?), grpc-tools
, google-protobuf
Running make fundoc
fails with
------
> [2/3] RUN cargo install fundoc --locked:
0.304 Updating crates.io index
291.8 Downloading crates ...
292.9 Downloaded fundoc v0.5.0
293.1 Installing fundoc v0.5.0
293.2 error: failed to select a version for the requirement `clap = "^4.1.8"`
293.2 candidate versions found which didn't match: 3.2.25, 3.2.24, 3.2.23, ...
293.2 location searched: crates.io index
293.2 required by package `fundoc v0.5.0`
------
Dockerfile:3
--------------------
1 | FROM rust:1.54.0
2 |
3 | >>> RUN cargo install fundoc --locked
4 | WORKDIR /opt
5 |
--------------------
As one example of a less standard JAVAish use case, AkkaGRPC has a quite good gRPC code generation. The recommended way is to reference a proto-files from a lib/jar.
Also new languages like Rust may benefit from this approach.
we don't need this anymore
absolut paths in imports currently don't work for example with BloomRPC
and the grpc cli
in service
import "article.proto";
vs
import "article/v1/article.proto";
Lines 79 to 85 in b03b09f
The nvm use
command did not work on my machine. The root cause is that we need to run both checks in a different node version locally. This would work with nvm
Currently only the Article
has a References
with the canonical link. For SEO reasons we also need this on all section pages.
message SectionPage {
repeated Stage stages = 1;
+ References references = 2;
}
message ArticlePage {
stroeer.core.v1.Article article = 1;
repeated RelatedArticle related_articles = 2;
+ References references = 3; // because of same logic for `Pages` in FE
}
The only downside of this is that the Article
and ArticlePage
has the same References
(duplication).
Many of the date fields (last_edited
, last_published
, created
) vanished from the CMS lately. After discussing this internally, we should cleanup those fields.
In addition, we can and should decide on whether to enforce: https://linter.aip.dev/142/time-field-names
Originally posted by @thisismana in #111 (comment)
As soon as we approach a stable v1
of our proto files, we should document our approach to versioning the APIs and the generated packages for node and java:
vX
packageLooking ahead for what will probably be added to tapir within the next months, I tried to create a concept for the future package structure
Soon we will open our API to other teams, until then we should have a plan for the api and reach some kind of stability
* page (ehem. pages)
* article
* ArticlePage
* ArticlePageService
*
* section
* SectionPage
* SectionPageService
* GetSectionPage
* page:1
* theme
* ThemePage
* ThemePageService
* author
* AuthorPage
* AuthorPageService
* simple?
* LandingPage?
*
* config {naming TBD - see proposals below}
* curation
* CuratedStage
* CurationService
* statistics
* TrackingService
* TrackingReport
* GetArticleIdByReport
* section
* Section
* SectionConfiguration
* SectionConfigurationService
* GetSectionConfig
* ModifySectionConfig
* AddSectionConfig
* DeleteSectionConfig
* personalization
* PersonalizationService
* api?
* auth
* client
* User
* UserService
* token
* Token
* TokenService
* ValidateToken
* GetToken
* limits
* RateLimit
* ScopeLimit
*
*
* content (ehem. core)
* article
* Article
* ArticleService
* teaser
* article
* TeaserService
* // content für paper um einzelne Bühnen nachzuladen
* // z.B. Regionaler Content für Regionales Bühne
* GetNewestArticlesForSection
* advertisement
* DisplayAd
* Format
* …
* TelekomAdTeaser
* page
* LandingPageTeaser
* TopicPageTeaser
* AuthorPageTeaser
*
* embed
* Oembed
* OembedService
config
pagackage name:config
page.building / pagebuilding / page_building,
page.management / pagemanagement / page_management,
page.control / pagecontrol / page_control,
site.control / sitecontrol / site_control
site.building / sitebuilding / site_building
…
As shown in the specs a package declaration follows the pattern:
package = "package" fullIdent ";"
i.e. the keyword package followed by a fullIdent followed by one ; semicolon, where fullIdent is defined as:
fullIdent = ident { "." ident }
i.e. at least one ident followed by zero or more other ident's preceded by ., where ident is defined as:
ident = letter { letter | decimalDigit | "_" }
i.e. at least one letter, followed by zero or more letters ([A-Z], [a-z]), digits ([0-9]), or the underscore _ character.
I want to change the coremedia
package name in my PR #83
coremedia
is a system and should not be included in Service DefinitionsAdding an example would help here:
Originally posted by @bobaaaaa in #111 (comment)
We need a concept for links (<a href />
) as part of a stage ("Mehr zu Sport").
should ad container placements be configured channel agnostic (apps vs www)?
possible Blocker
requirements engineering necessary
core.Article.Metadata.state
is currently a string
field which isn't used anywhere in the API (we delete articles which do not return a 200
from the CMS).
Questions:
UNSPECIFIED
, PUBLISHED
, ...)?message GetArticlePageResponse {
stroeer.core.v1.Article article = 1;
repeated RelatedArticle related_articles = 2;
}
message GetSectionPageResponse {
stroeer.pages.section.v1.SectionPage section_page = 1;
}
message GetArticlePageResponse {
stroeer.pages.article.v1.ArticlePage article_page = 1;
}
message GetSectionPageResponse {
stroeer.pages.section.v1.SectionPage section_page = 1;
}
message GetArticlePageResponse {
stroeer.core.v1.Article article = 1;
repeated RelatedArticle related_articles = 2;
}
message GetSectionPageResponse {
repeated stroeer.core.v1.Stage stages = 1;
}
we should put the sources of stroeer/protoc-dockerized
and scripts to build it somewhere/in this repo
enums for stable values (e.g. subtypes, maintypes,..)
strings for changing and temporary things (e.g. stage layouts)
This seems like a bug - publication_date
is part of the fields
map.
Bump all projects + docker image to protoc 3.15.0
See:
https://github.com/protocolbuffers/protobuf/releases/tag/v3.15.0
make
to build all the files locally, for all the supported languagesmake release
to create a release and git-tag (ideally auto-incremented by either minor/major/patch)make test
to locally run testsstick to one build tool (e.g. no additional scripts such as build_docker.sh)
Some of our ContentSubType
values are deprecated and can be removed (see internal ticket).
To generate breadcrumbs we need the section_path
on the GetWebSectionPageResponse
message.
Currently a WebArticle
has a section_path
field. Maybe it make more sense if both GetWebSectionPageResponse
and GetWebArticlePageResponse
includes a more structured section_path
field.
message GetWebSectionPageResponse {
// ...
repeated string section_path = ?
}
const sectionPath = ['', 'sport', 'fussball'];
We currently use a dockerized protoc
for generating java and a binary protoc
installation for node
(which is also used on GitHub actions for both languages).
We should use a dockerized version for all languages we want to support which also works on CI.
Assets.relations seems not necessary.
At some point we need some documentation for some code conventions. Examples:
BodyNode.type
stringsfields
keyshttps://github.com/pseudomuto/protoc-gen-doc
The Buf Schema Registry (BSR) could be an interesting enhancement to our toolchain:
The BSR stores and manages Protobuf files as versioned modules, so that individuals and organizations can consume and publish their APIs easier than ever before.
The BSR comes with a browsable UI, dependency management, API validation and versioning, autogenerated documentation, and an extensible plugin system which enables remote code generation.
Currently we save date fields in UTC strings, we could also use Google.Protobuf.WellKnownTypes.Timestamp to maybe skip all the necessary parsing of string to date in the clients.
Here is list of all inconsistencies I found while migrate to 0.3.0
. And some thoughts about the services: There is a Request
object (GetArticlePageRequest
) but no Response
object (only WebArticlePage
). This looks odd.
web_article.proto
- message RelatedArticle {
- WebArticle article = 1;
- RelatedArticleRole role = 2;
- }
+ message RelatedWebArticle {
# or main_article
+ WebArticle web_article = 1;
+ RelatedWebArticleRole role = 2;
+ }
web_article_service.proto
GetArticlePageRequest
-> GetWebArticlePageRequest
rpc GetArticlePage
-> rpc GetWebArticlePage
web_section_service.proto
GetSectionPageRequest
-> GetWebSectionPageRequest
GetSectionPageResponse
-> WebSectionPage
article.proto
message Element
: the field content_id
-> article_id
(the message type is Article
not Content
enum ContentType
: CONTENT_TYPE_ARTICLE
-> CONTENT_TYPE_NEWS_ARTICLE
. There will be a OPINION_ARTICLE
https://github.com/stroeer/tapir/blob/master/.github/workflows/docker-release.yml#L24
currently each docker push will overwrite tag 3.13.0
https://www.conventionalcommits.org/en/v1.0.0/
feat(node): add esm bundle
feat(proto): add new model
ci: use ubuntu-latest
https://www.conventionalcommits.org/en/v1.0.0/#why-use-conventional-commits
Currently, we only have:
ArticlePage.Article.type
ArticlePage.Article.sub_type
I would like to introduce the following addition (naming tbd):
SectionPage.Section.type = 'section'
SectionPage.Section.sub_type = 'news' | 'frontpage' | 'advertorial' | 'themepage'
In paper is already a type section
. This makes it much easier for us to calculate standard info/properties/values in some places. We have an interface Page
shared between Article- and Section-Pages.
/test-homepage/
could also have the sub_type
frontpage
./themen/*
with sub_type
themen
for easier cache header/authors/
with sub_type
author
for custom commercial settingsIs there a reason why both of them are main content types? In paper we ignore them completely.
tapir/stroeer/core/v1/article.proto
Lines 225 to 249 in ee2c8ae
The process of adding go code to this repository should be automated.
Currently only the relation
field of Element
is not an enum
. When things about the article body are clear we should migrate here to an enum
as well.
message Element {
ElementType type = 1;
string guid = 2;
repeated string relations = 3;
repeated Asset assets = 4;
string article_id = 5;
}
The web
APIs have been replaced by their pages
counterparts. Changes of #50 need to be merged into the SectionPageService
and then the web
folder can be removed.
we currently use string
as the data type for article ids (in core
and web
). If we keep on using numeric database ids, we should migrate this to something more efficient like uint64
.
On npm there is a deprecating setting for packages: https://docs.npmjs.com/deprecating-and-undeprecating-packages-or-package-versions. Currently, GitHub packages did not have these setting.
In case GitHub packages get it -> enable it for: https://github.com/stroeer/tapir/pkgs/npm/tapir-v1-legacy
possible blocker to get the new WebSectionPage into production
e.g. stage with two editorial teasers, and an Ad on 3rd position, but maybe on 1st position tomorrow
e.g. inhouse teaser placements
e.g. widgets rendered as teasers (Google Maps widget, finance widget, news from other publishers,....)
requirements engineering necessary
Currently Article.type
and Element.type
share the same enum ContentType
, after checking the requirements we might come up with two distinct enums here since not all elements
might be an article
.
We need a quick way to perform load tests for the @grpc-js/grpc
and grpc
client of tapir. This is also some kind of documentation for other teams.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.