refs https://github.com/TryGhost/Arch/issues/99
- This is a naive implementation mostly based on existing bookshelf approach. It's up for discussion if doing aggregation inside of the browse method is a right call or this data should be separated into a different method
- To reiterate, the aim for initial spike is to make the cod work using nest and figure out better patterns iteratively while it's fresh.
refs https://github.com/TryGhost/Arch/issues/99
- The timezone formatting was dropped from the migrated implementation because we do not do the formatting in the legacy API (incorrectly imo). We only do the timezone formatting on Posts API endpoints.
- Adding formatting for migrated Snippets API would mean a breaking change, which we don't want to make just yet
refs https://github.com/TryGhost/Arch/issues/99
- Only posts resources ever have the dates formatted in the legacy API. There's no need to implement this formatting in Snippets API at the moment
refs https://github.com/TryGhost/Arch/issues/99
- This is a very crude implementation that showcases moving pieces that are needed to make Snippets API work with NestJS
- The snippets api e2e test suite enables the `nestSnippetsAPI` flag to allow testing nest implementation of the GET /snippets endpoint
refs https://github.com/TryGhost/Arch/issues/99
- The Snippets repository allows to fetch Snippet entity data through the legacy bookshelf models. The bookshelf should be substituted with knex wherever possible, once we have reached the feature parity and stability with the legacy Snippets API.
refs https://github.com/TryGhost/Arch/issues/100
- Because of the way how new NestJS code is integrated into existing Ghost I've introduced a way to "skip" rather than "block" access to certain API endpoints when the labs flag is enabled.
- This change skips the `GET /snippets` legacy Admin API route and falls through to the NestJS route
refs https://github.com/TryGhost/Arch/issues/99
- Adds connection between snippets in NestJS application to the models in the legacy Ghost codebase to link snippets to real data
- The NestJS controller code can be executed by commenting out `router.get('/snippets', mw.authAdminApi, http(api.snippets.browse));` in the ghost core Admin API routes file
refs https://github.com/TryGhost/Arch/issues/99
- This is scaffolding for the Snippets API controller
- The change includes a basic controller, service and a test to get the ball rolling
- In the Nest code we are writing an example of the ideal code. The ESlint rules will adjust to how code is written in this project eventually once we experiment with things enough.
- Examples of new naming convention are based on `.` separator e.g.:
- The middle words represent use cases, could later become pods e.g. posts.controller.js, posts.repository.js, posts.dto.js, posts.service.js, posts.scheduling.service.js, stripe.provider.js, stripe.webhook.listener.js.
This updates the AdapterCacheRedis instance to be able to handle updating
itself when reading from the cache. For this to work we need to pass a
`fetchData` function to the `get` method.
In the case of a cache miss, we will read the data via the `fetchData`
function, and store it in the cache, before returning the value to the caller.
When coupled with a `refreshAheadFactor` config, we will go a step further and
implement the "Refresh Ahead" caching strategy. What this means is that we will
refresh the contents of the cache in the background, this happens on a cache
read and only once the data in the cache has only a certain percentage of the
TTL left, which is set as a decimal value between 0 and 1.
e.g.
ttl = 100s
refreshAheadFactor = 0.2;
Any read from the cache that happens _after_ 80s will do a background refresh
Having the code use `async/await` make it more readable, and extracting the
execution to a separate function make its easier to run in the background in the
future
This logic is so simple it isn't worth having the indirection of another class.
This also removes the indirection of wrapped getters/setters, which is useful
because otherwise we need to update the wrapper with new methods each time
theunderlying implementation is changed. There was a note about losing the
context of this, but I haven't found anywhere that the context is lost.
no issue
- potentially fixes a small performance issues to avoid the homepage of
your publication from being loaded should an href from Portal not exist
when loading Offers, that could cause flashing.
