React-starter-kit: Any thoughts on adding example code on how to set RSK up with migrations and seeds?

[iDVB]

We're loving RSK, but there seems to be a few missing pieces with relation to examples. Things like migrations/seeds (sequelize-cli), graphQL mutations and graphql queries that actually query the models that are set as an example.

[langpavel]

I'm database guy, I love postgres, I love plain SQL scripts, I love control under my hands.
My advice is: Keep plain SQL files, one updated to recreate schemas for tests and as reference,
one file per version to shift up.
Automation in SQL migrations is source of greatest catastrophes! :-)

[frenzzy]

You may consider the use of Node.js API Starter Kit as a backend for React Starter Kit.
There are examples of migration for PostgreSQL... ref #1057

[iDVB]

@frenzzy Mind blown. :P We've been using RSK for both Web and API up to date and we're talking about how it would be better if the API was its own container/app.

Nodejs API Starter Kit seems like just the boilerplate to help kick start it. Especially since it seems to have Migrations far more stubbed out.

Thanks for the hint.

[buildbreakdo]

@iDVB RSK already uses sequelize, would install the sequelize-cli globally (npm install sequelize-cli -g), create a data folder at the root of the directory (RSK data folder should be at root like public) and run sequelize init from the command line in your root data folder and everything will be generated for you (skeletons for models/migrations/seed/config).

More info at the repo:
https://github.com/sequelize/cli

[iDVB]

@buildbreakdo not sure that what your suggesting is any different than we're already doing. My point above is more just to point out some of the things that could be further flushed out. Though after looking at 'nodejs API starter' it appears that is what they are trying to do outside of the RSK boilerplate which I think makes more sense. We leveraged RSK for both API and Web "because it was all there and we needed it all" but the further of our specific project will likely be to move our API out of our web container and into its own one where we can implement something like no nodejs API starter'

[buildbreakdo]

@iDVB Goal was to give a heads up that a best practice seed/migration/model/config boilerplate example could be generated with sequelize init. Definitely are opportunities to flesh out some of the examples in the RSK (especially around the database).

Additional discussion has been had here about when to shift to an external API: https://github.com/kriasoft/react-starter-kit/pull/1057

[langpavel]

@buildbreakdo:

when to shift to an external API

When you have separate team.

If not and/or you have low resources, you can benefit from fact that this kit is well horizontally scalable. API in means that SSR can be much cheaper to CPU→RAM→money. See this loopback which is incredibly efficient

[buildbreakdo]

@langpavel Have thought about shoving SSR for dynamic content into a lambda function on AWS.. then would be truly pay as you go. Otherwise, for static content upload directly to S3 CDN enabled and direct traffic from an app aware load balancer using content based routing directly to S3 (no need to go through an intermediary server this way).

https://aws.amazon.com/elasticloadbalancing/applicationloadbalancer/ <-- pretty cool

[langpavel]

@buildbreakdo Hmm.. I'm not sure what you think.. I have own VPS for RSK projects so I don't need evaluate something else (AWS, Heroku, Nodejitsu...) yet...

My point of view is: As this kit is build now, you only request SSR at very first HTTP request. After then application lives purely inside browser, doing only GraphQL requests which cannot be cached on HTTP layer. (Of course, they can in limited cases, but implementing this will be more costly then beneficial in most situations).

You can also implement ServiceWorker, so you can achieve worker-side rendering, which can be relatively easy - just provide no prerendered page at all, only include assets in, then browser will do the rest.
You effectively skip SSR inside most browsers for returning visitors! :tada:

[Jaikant]

Having SSR work with lambda could save money for many users who otherwise would use AWS instances or Google cloud etc. I think it is of much value.