[Discussion] Application data arquitecture

[joaogarin]

so In my opinion we could start by fetching the categories from JsonAPI. When you go to the recipes landing page that would be the starting point and that will give us stuff like "latest", "main course", "starters" etc. This should be done immediately at the beginning on the Recipe landing page, and we can try and cache this information so that we dont overfetch (if we navigate in and out of this route)

with each of those we can then start getting recipes. Doing a call like getting recipes by category, where the necessary information for teasers will be delivered. Here its basically the url "/recipes" so a limited amount of recipes should be loaded..like 4 per category or something like that.

we would then on each of them have a "load more of this type" which would go to for example the route "/recipes/starters" (if clicked on starters load more)

here the list could be a longer one I guess but still the same query than previous (fetching for teasers)..only with a larger amount of items to be returned (increasing limit).

From every teaser you can also click on "More" and go to the recipe detail page, there extra information about a recipe is fetched.

ngrx

In terms of the store I would have a categories list and a recipes list. the Recipes list would have multiple actions to populate different parts maybe..since on the teasers only certain info is needed we don't need to fetch early some of the information that might not be relevant. Services would handle getting information from jsonapi and populating the store.

Components would then subscribe to the parts of the store they need.

JsonAPI communication

I really liked the package that was created by @nyl-auster, I think it makes communication with json api simple and we could take advantage of it. We would need to created a typescript definition file for it. I plan on trying that out, and would be also cool to export it as an actual module.

I think this package makes the query a bit more clear..and sounds like something I think we could try..so you don't really have to think abouyt the jsonapi internals..Let me know your thoughts.

Components

Regarding components I think the pattern we are going for is quite common, the only one that bothers me is having "Recipes" inside the "components" folder since its actually a module, and it should also have "components" and "services" of his own..but we can move it out at any time.

The pattern here is of course to have as much reusable components as possible. We could discuss splitting our container and UI (stateless whatever you want to call it) into different folders.

Tests

Lets try and have really test for each and every component, service etc..Also I am working on a mechanism so we can mock the store for the components we are interacting with the store. Mocking in angular is pretty easy we can discuss these details at any time. I made a PR to fix some tests as soon as that is merged I will work on some of these trickier components to test like the recipe-list which we will need to mock not only the store but also the service that fetches the data from jsonapi.

Let me know your thoughts on this and see if we can really define this so that we can build out a working sample of the app a bit quicker and everyone knows and agrees on the path to follow ;)

[joaogarin]

Link to the package : https://www.npmjs.com/package/d8-jsonapi-querystring

[dawehner]

It is interesting, when I tried to implement the category landing page I thought treading the categories different to normal tags. Categories are a limited list of taxonomies, while tags are basically arbitrary. This means that the frontend application could assume that there are just 4 different categories. For me the easy solution was: let's hardcode that in the frontend, as well, it makes life easier. This is of course an choice frontends can make, but I think one major reason why building things decoupled seems so much more productive is because you can make certain shortcuts Drupal can't do in all of its generality.

[joaogarin]

Yeah I totally agree on simplifying at least now to get things going where possible. I think getting them from contenta is not a super extra effort. It is an extra request, but one that eventually will have to exist probably.

But looking at cooking sites and all I think its fair to assume thats where it starts, with categories and from the drilling down to the actual recipes. Also thats what in the wireframes;P

[yann-yinn]

Hello ! thx for the package and glad if it might be useful for someone else.

I follow the same straightforward path for now : requesting categories and then launch in a Promise.all() all requests to get Recipes By Categories.

No cache for now, want to see if this straightforward way works as it is, without being to slow.

Browser is supposed to serves category (and maybe listing) from its local http cache for all next GET requests. If not, we should fix that (cache header from contenta )

[e0ipso]

I'm letting you know that Contenta makes drupal.org/project/subrequests. Sounds useful for what you need?

[yann-yinn]

@e0ipso sounds unclear for me :

• you send a document describing a list to http requests you want to do
• you send this document to the server
• Server translates this http request calling the appropriate controllers ?
• And then return ONE http response will all you need ?

So only one http get request is made ?

[e0ipso]

One request and one response (with subresponses).

[yann-yinn]

I tried first a straightforward implementation : request categories then launch one http request by category to see if it is slow or not: here it is : https://contentavuedemo.github.io/recipes

(below is how i fetch data for recipes page )