0.3.27

Full Changelog: 0.3.21...0.3.27

0.3.21

What's Changed

Mainly tests, coverage and dependencies version updates.

• Docs/markdown documentation by @amerah-abdul in #6

Full Changelog: 0.3.11...0.3.21

0.3.11

What's Changed

• Test/add tests ingest by @amerah-abdul in #5

Full Changelog: 0.3.10...0.3.11

0.3.10

New API Methods

res.fromStatusResponse() - imports a status response object to the response.

res.fromStatusResponse({
  code: 200,
  status: 'OK',
  results: { foo: 'bar'} ,
  total: 1
});

res.toStatusResponse() - exports a response to a status response object .

res.toStatusResponse(); //--> { code: 200, status: 'OK' }

server.call() - a shortcur to emit, that can auto create a request and/or response and return a status response object

const response = await server.call('foobar', req, res);
const response = await server.call('foobar' { foo: bar });
const response = await server.call('foobar');

server.routeTo() - Allows routes to call on other routes without redirecting. Return a status response object

await server.routeTo('get', '/foo/bar', req, res);
await server.routeTo('get', '/foo/bar', { foo: bar });
await server.routeTo('get', '/foo/bar');

Full Changelog: 0.3.6...0.3.10

0.3.6

SFIAL Version

(Serverless Functions is a Lie) Ingest was designed under the assumption that serverless was designed for one unit of function. This is why the server limits are lower than a normal cloud or dedicated server. Serverless functions bundles serverless and a API gateway, but under the hood it just uses one function to process all the routing. You can visualize this as stuffing an entire app into one unit of function and that one function is ran on serverless (as compared to a Kubernetes approach to auto deploying to multiple serverless functions per entry file). While convenient for the service provider, it can cause server limits to be exceeded more often than not.

Under these circumstances, we rewrote Ingest with the following simple directives.

• Back to basics design
• event driven routing
• In memory routing, first
• entry file routing, second
• Pluggable. Modules can intro functionality.

What's Changed

• Feature/new added tests by @amerah-abdul in #3
• 0.3.0 by @cblanquera in #4

New Contributors

• @cblanquera made their first contribution in #4

Full Changelog: 0.2.14...0.3.6

0.3.0 alpha

Just tagging this state because it's working using action functions.

What's Changed

• Feature/new added tests by @amerah-abdul in #3

Full Changelog: 0.2.14...0.3.0-alpha.1

0.2.14

Pluggable Pattern

Use of plugins are optional in Ingest. The ingest pluggable pattern allows 3rd party libraries to push functionality to your app. Consider app.ts in an example project.

// [cwd]/src/app.ts
import { Factory } from '@stackpress/ingest';

const app = new Factory({
  //location of plugins
  plugins: [
    './dist/plugin/session'
    'package-in-node-modules'
  ],
  //file to look for in each plugin
  filenames: [
    '/plugin.js',
    '/plugin.json'
  ],
})

We can create a new plugin [cwd]/src/plugin/session/plugin.ts with the following code.

// [cwd]/src/plugin/session/plugin.ts
import type { Factory } from '@stackpress/ingest';

export default function plugin(app: Factory) {
  app.config.set('session', 'abc123');
};

When we call await app.bootstrap(), all plugins will be loaded. Specifically app will have a session found in app.config('session'). While this is good for initial setup, we can go deeper and plugin at certain points of your app using events. Consider the following code.

// [cwd]/src/plugin/session/plugin.ts
import type { Factory } from '@stackpress/ingest';

export default function plugin(app: Factory) {
  app.config.set('session', 'abc123');
  app.on('session-signin', (req, res) => {
    //encode password using 'abc123' ...
  });
};

You can see a use of plugins here: https://github.com/stackpress/ingest/tree/main/examples/with-vercel

What's Changed

• Feature/new added tests by @amerah-abdul in #2

New Contributors

• @amerah-abdul made their first contribution in #2

Full Changelog: 0.2.10...0.2.14

0.2.10

Callable

Request props (data, headers, session, query, post), Context props (data, headers, session, query, post) and Response props (headers, session, errors) now are callable functions used to retrieve data within their respective objects. For example:

req.data('id')
//is the same as...
req.data.get('id')

Full Changelog: 0.2.7...0.2.10

0.2.7

Context

Framework now passes Context instead of Request in entry files. Before entry files use to look like the following.

import { Request, Response } from '@stackpress/ingest';

export default function UserDetail(req: Request, res: Response) {
  //get params
  const ctx = req.fromRoute('/user/:id');
  const id = ctx.params.get('id');
  //maybe get from database?
  const results = { 
    id: id, 
    name: 'John Doe', 
    age: 21, 
    created: new Date().toISOString() 
  };
  //send the response
  res.setResults(results);
};

Contexts are shallow copies of Requests with the routes like /user/:id already processed. It now looks like the following code.

import { Context, Response } from '@stackpress/ingest';

export default function UserDetail(ctx: Context, res: Response) {
  //get params
  const id = ctx.params.get('id');
  //maybe get from database?
  const results = { 
    id: id, 
    name: 'John Doe', 
    age: 21, 
    created: new Date().toISOString() 
  };
  //send the response
  res.setResults(results);
};

Take into consideration a route like /user/:id and a route /user/search. If the URL being requested was https://localhost/user/search, both routes would match and be triggered, but /user/search should not care about :id. Thus these are 2 different request contexts. Contexts have a param property that extract the route parameters from the route string. To get the ID in /user/:id you can do the following code.

ctx.param.get('id');

Stage Data

request and context now merge the data from query, post and param in that respective order and stores that merged data inside the data property. Entry files that intends to be used across many mediums (ie. http, terminal, socket requests) should use data instead of post/query/... in order to be agnostic.

// ex. /user/2?name=doe
const id = ctx.data.get('id'); //--> 2
const name = ctx.data.get('name'); //--> doe

Full Changelog: 0.2.6...0.2.7

0.2.6

Beta 2

Reorganized and simplified the project in a way there is a clear separation between build time and run time libraries.

Full Changelog: 0.1.25...0.2.6