flypapertech / avian Goto Github PK

There is a need for components to have the ability to schedule timed events. This is being implemented in a fairly sophisticated way in which at regular intervals Avian will check all components in an application to see if there are cron jobs that need to be executed. If so, they are added to a queue within Redis. Equally as often is a check being done by Avian where it looks to see if jobs are available to be ran from the queue, if so, it will assign a job worker (cpu core) on the application. If Avian is being ran in a distributed configuration, where there are multiple Avian's hosting the same application, these considerations to run cron jobs will be shared across the entire cluster.

This stemmed from a need to have views be aware of which "mode" they are in. Ultimately, all command line arguments passed to Avian should be known to an applications view layer, in my opinion.

They're both the leading in memory data storage platforms. AWS and its ElastiCache provide managed services for them. Redis generally seems to win because of how much you can do with it, but memcached is being to be more simple, and slightly faster. We should offer this as an alternative.

After some discussion with @Logikgate, and our future need to have, at runtime, Avian compile ES6 modules to be used by the server, we've changed the static directory to public, and now have a public directory for internal compilations.

This feature is about extending Avian's logging capabilities from simply banyun logging to fluentd as well.

https://www.npmjs.com/package/@types/redis

As it stands now Avian requires that Redis be accessible. In nearly all cases of production and scale, this is the obvious choice, but out of the box, Avian will complain if it can't find Redis locally running and accessible. We'd like to have an out of the box solution for getting people started, and as they grow their app they can move over to using more powerful caching databases like Redis, maybe even memcached.

User's can already override Avian routes by using the avian.service.ts(js) file. They should also be able to override any of Avian's underlying Express settings. One idea is to pass the Avian express app to the avian.service.ts(js) file so that the user has a reference to it to do with as they desire.

The ability to create files like, component.server.migrations.ts, or component.server.api.ts.

In our own application we use at FlyPaper, we've created a cool feature where we can have a middleware executed as an epilogue to a service file route.

If we're going to support multiple logging frameworks we should really take advantage of some of their unique capabilities. For instance, Bunyan can be made capable of treating each component, as a child, allowing for logging steams to be unique to each component in an Avian application.

This is worth investigating...

We had problems with the last implementation but needed to remove it for development purposes. However it's a little tiresome having not having index by default.

So what does this really mean... well, it means supporting prometheus in cluster mode. It will expose a cluster metrics route, allowing a visualization tool such as Grafana, DataDog and others, to visual performance metrics of the application itself. This, coupled with node-exporter-prometheus, we can gain per route performance metrics that can be exposed to the promql language and again, be visualized.

After our discussions today, we decided that we should always have such a file available to a component, though not required. We renamed this "config".

We've started doing this in naming only, within some of the Avian cli/lib files. But we still only support express routes authored within component.service.ts/js.

Layouts, structured much like components, should be scanned in the same manor.

This is the bundling and tree shaking functionality that will be built into Avian. @Logikgate has already completed several hours of research on the subject. The current implementation is using Webpack. Though this may change.

On a project that I'm working on, we finally ran into the forseen issue of needing component specific routes beyond what Avian provides out of the box. This feature has been apart of the main design of Avian since its early days. But now, I finally have good cause to focus on it. I believe this is a game changing feature for Avian.

This really just works. But I've yet to add it to Travis CI. I've noticed some simple errors on Node 10 but no functionality (that I know of) is broken.

Since its inception, Avian was imagined to be not a framework, but a platform for running applications. With the advent of LXC containers, then later the Docker and Kubernetes ecosystems, we are now able to provide Avian in such a platform. Avian is well suited for the ephemeral and embarrassingly parallel architectures now commonly used in the enterprise. This issue is to provide an official Avian Docker image on the FlyPaper Tech organization on Docker Hub. Where developers can build their Docker based applications FROM the Avian container itself. Allowing them to focus the application itself, and not the underlying operating system.

Now that avian supports any express compliant rendering engine that is added as a dependency to a user's application should we remove the few that we explicitly supported in the past from Avain's dependencies? (pug, handlebars and ejs)

This way we won't be maintaining modules that may or may not be used and each user will have full control over which version of the rendering engine they want to use since it will be in added to their project as a normal dependency.

The argument against this is that if a user wants to use, for example, pug then they need to manually run npm -i pug --save rather than it just working out of the box. Not that that is a big thing to ask.

Basically, the --mode, --home, etc, should be available to an Avian application at run time. See #11 for an example of what I mean.

All of the popular Process Managers offer the clustering capability. PM2, StrongLoop, Forever, support applications not designed for clustering, and will expand across max CPUs to provide load balancing and failover across cores. Avian should make --cluster a first class option. Where we allow someone to NOT have to use clustering. Or, if using clustering, you can set the max number of workers.

Avian, since its infancy, has only supported a locally running redis store. We should make it possible to specify an external redis server. This better facilitates a cluster of avian servers pointing to an external redis cache.

Decided this would be a better name. Webpack considers the entrance to your app an entry and Docker uses the term entrypoint as well. Figured it made sense and was a better name.

Working on ensuring our out of the box webpack works with Vue templates, as well as these template engines. It should :) But we will need to verify. Right now we know that html and pug work.

This is useful in development environments when you do NOT want avian to do things like nuke public/private, re-webpack everything, etc... just "start" the server please.

Dans-MacBook-Pro:protest danstephenson$ avian
(node:7661) [DEP0091] DeprecationWarning: crypto.DEFAULT_ENCODING is deprecated.
Avian - Core: 1, Process: 7661d, Name: localhost, Home: /Users/danstephenson/Projects/flypaper/protest, Port: 8080
(node:7662) [DEP0091] DeprecationWarning: crypto.DEFAULT_ENCODING is deprecated.
Avian - Core: 2, Process: 7662d, Name: localhost, Home: /Users/danstephenson/Projects/flypaper/protest, Port: 8080
(node:7664) [DEP0091] DeprecationWarning: crypto.DEFAULT_ENCODING is deprecated.
(node:7665) [DEP0091] DeprecationWarning: crypto.DEFAULT_ENCODING is deprecated.
(node:7668) [DEP0091] DeprecationWarning: crypto.DEFAULT_ENCODING is deprecated.
(node:7663) [DEP0091] DeprecationWarning: crypto.DEFAULT_ENCODING is deprecated.
Avian - Core: 4, Process: 7664d, Name: localhost, Home: /Users/danstephenson/Projects/flypaper/protest, Port: 8080
Avian - Core: 5, Process: 7665d, Name: localhost, Home: /Users/danstephenson/Projects/flypaper/protest, Port: 8080
Avian - Core: 8, Process: 7668d, Name: localhost, Home: /Users/danstephenson/Projects/flypaper/protest, Port: 8080
Avian - Core: 3, Process: 7663d, Name: localhost, Home: /Users/danstephenson/Projects/flypaper/protest, Port: 8080
(node:7667) [DEP0091] DeprecationWarning: crypto.DEFAULT_ENCODING is deprecated.
(node:7666) [DEP0091] DeprecationWarning: crypto.DEFAULT_ENCODING is deprecated.
Avian - Core: 7, Process: 7667d, Name: localhost, Home: /Users/danstephenson/Projects/flypaper/protest, Port: 8080
Avian - Core: 6, Process: 7666d, Name: localhost, Home: /Users/danstephenson/Projects/flypaper/protest, Port: 8080

We will maintain the current functionality, however, as applications grow larger, it makes sense to support scaffolding.

Without getting into the details module exports for express don't seem to support es6 natively for routes that need to be discovered dynamically. Essentially imports can't be used dynamically only statically. Require is used for dynamic "importing" of modules. Or, services in this case. So, routes, can't be written using ES6 exports. However now in Avian they can be.

We use Yarn now so we should update the README.

This one is gaining traction. It's more similar to fluentd in how it can handle multiple streams of logs and then unify them into a single normalized data collection.

So what does this mean? Well I'll tell you. Avian exposes a few publicly available directories for your application. For many frameworks, these are known as the "public" directory, or the "static" directory. Avian already allows you to select which of these is to be used to host static files. You can even choose which one serves static files at /. This is cool.

But one thing that Avian supports that most frameworks do not, is a natively available /assets directory. Many modern application frameworks organize UI related "assets" in a directory known as "assets". It's very common, and you see it more and more. This is why since in the very early days of Avian we acknowledged that this directory could exist in your app home, and we should make it exposed to the internet.

Great, ok...

But wouldn't it be cool if that assets directory could also break up assets like "less, sass, pug, ejs, and even ts files?" Yes it would.

The "static" and "public" directories would work as they do now, they are express.static directories and so there is no way that I know of to preprocess files behind rendered before being exposed to the client.

That's fine. But with assets, we can make it not a static directory. We can have the directory exist, yes, we can have it serve assets, yes, they can even be static, yes, however, if a file being called from /assets/pug/myexample.pug is requested, Avian would be intelligent enough to render the file into html. Same with the other template engines and css preprocessors we support.

We should do this. I don't know of other frameworks that do. Sure, yes, there is a performance penalty for doing this for those files but, if you want to do it you should be able to.

Specifically Express, Node, and the Jasmine test spec.

We need component views to be capable of understanding what parameters have been passed to them. Specifically during server-side rendering.

It's fast, simple, based on Bunyan, and is extremely popular now. It's possible we could even consider making it the default logging framework when not needing something more advanced, like say fluent.

This has been resolved.

Numerous new command line switches exist. We should document them.