Skip to content

Instantly share code, notes, and snippets.

@kirrg001
Created March 13, 2018 10:26
Show Gist options
  • Save kirrg001/8b3e5990eae4027288e9d83abb63de54 to your computer and use it in GitHub Desktop.
Save kirrg001/8b3e5990eae4027288e9d83abb63de54 to your computer and use it in GitHub Desktop.
- research memory usage of UrlService
- finish up url service
- urlService utility needs a rewrite
- e.g. if i change / to /home in my yml file and i call urlService.urlFor('post', data), i would receive /welcome and not /home/welcome
- i think post.url must die on the model layer (!) -> this is nothing the model has knowledge of -> different layer (routing)
- but we still need to ensure that we return the current post url to the admin interface
- need to dig into that part a little deeper
- same for tag: the url utility uses static route keywords, but instead we need to use the taxonmoies/resources of the yml file (!)
- i think some of the routing keywords must die???
- which data is required to fetch for the urlservice?
- id, slug, type is currently remembered
- memory currently goes up because we fetch all attributes, but we only keep a minimal set in process (memory goes up and goes down after ~2mins)
- we can reduce the memory by using "columns: id, slug"
- i think the url service should not cache the whole data set right now
- i think the urlservice could use a DataCache, which can be disabled/enabled -> but this is a different feature
- for now the url service just knows which urls are available in the service
- if the first request comes in, we have to ensure that the url service did finish it's url caching
- > need to be able to apply filters to existing JSON objects, to see if they match. Therefore reworking and extending GQL is a must.
- this happens because the urlsrvc fetches all the data on bootstrap
- now it has to figure out which post belongs to which collection
- based on FILTERS (which actually run against the db)
- the question now is: should we rewrite GQL to see if objects match a filter
- OR should we fetch the data already based on the route patterns
- that means the component, who instantiates collections etc, will trigger the urlsrvc to cache a set of routes
- we also need to keep in mind, that we might need a similar logic for apps ? e.g. /subscribe
- e.g. fetch filter=x for /podcast/:slug/
- if we run them sequentially, the urlsrvc is able to keep unique urls for each post
- ????????
- what we then need to do is, if we register /nature/:slug as express route, we have to ensure the UrlSrvc has the requested url
- alternatively, we don't register ANY routes in express and use a * and ensure the url is known in the UrlSrvc
- the event listeners in the url service won't work anymore
- needs a little rewrite
- because currently it just calls toUrl, which does not return the correct url
- sitemaps rewrite ??????
- if the urlsrvc does not cache any data, except of the urls, why should the sitemap generator request the urlsrvc?
- sitemaps generator needs more information e.g. modified date, images
-
- write the channel controller
- handles rss (if not disabled)
- handles pagination
- fetches the data
- write the basic controller
- write collection class
- this.controller = ChannelController
- write resource/taxonomy class
- this.controller = ChannelController
- write routes class
- this.controller = BasicController
- base class of these three types will be able to resolve resource paths e.g. page.home
- yml file reader + parser
- default yml file lives in the Ghost core tree
- if you provide a custom yml file, we prefer this file
- we fallback to the default yml file if we can't read the custom yml file
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment