ENGINEERING: Create reference app using stack from engineering handbook; communicate to team

[simonwex]

We need a reference application we can all refer to when suggesting changes to our stack.

Phase: Build / Ship Owner: @simonwex Decision: @simonwex Lead design: n/a Lead dev: @Pomax Quality: @jbuck Dev: @alicoding

[simonwex]

Hey @alicoding, could you lend @Pomax a hand with the l10n part of the ref app?

[simonwex]

@alicoding could you add whatever fix you apply here https://github.com/mozilla/webmaker.org/issues/1066 to this app?

[Pomax]

The intention is to implement a 'mini webmaker' with a client side app/ui that lets you CRUD simple makes, and the webmaker login tied into it because almost everything we make will end up using that.

Looking at the app from the traditional roles, I'd identify things as:

• [ ] housing the client's software and the resources required for that to do its job

  React app, served as static app, generated from less/jsx/etc using automated build (i.e. gulp, browserify, and friends). Open question is how much routing needs to go in the client UI vs. route handling by the server. A lot of data can simply be requested after the initial UI startup, as a bootstrap, so "what is wisdom" here is possibly still up for debate. I suspect we'll do a bit of both. This will also need to be written in an i18n-friendly way. In the sense that proper i18n functionality is non-negotiably essential.

• [ ] housing the data you want your users to consume

  Specifically, the data storage and management aspect. I don't know if we want a SQL or NoSQL solution but regardless of what we pick we'll need to exemplify our connector, as well as schema migrations at the very least

• [ ] facilitating computation that clients cannot (reasonably) do themselves

  take "computation" with a grain of salt, basically this is all the "X as a service" things we do (basically APIs that let the the user, or our client UI, offload requests for processing somewhere else)

• [ ] exposing "the data" to "the clients"

  I'd like to keep this as API based as possible: rather than dynamically creating lots of pages, have the server service API endpoints for things like /user and /makes/list which send json over to the client, which then does what needs to be done to show those things, and perform state changed based on being logged in or not, etc.

[jbuck]

humbly suggesting we take a long hard look at https://github.com/yahoo/react-intl for internationalization

[simonwex]

@alicoding ^

[thisandagain]

@simonwex @Pomax Do you want / need to continue work on this in earnest or are we good to close this sprint ticket?

[alicoding]

There is localization part where I'm currently working on but it could be in its own ticket.

[simonwex]

@alicoding could you create that ticket?

[alicoding]

Sure thing @simonwex just regular format not like this one right?