Show HN: A minimal setup for React/ES6 sites with a Firebase back end
github.com
github.com
From the people I talked to it seems that the main audience for firebase is mobile engineers that either don't have the skillset or the time to learn how to build a backend system. Most people I talked to also told me they wouldn't use firebase if they could build a backend.
I could see Firebase being a great go to for a certain size of project in the small to medium size that would rather pay for this feature set that using AWS, Azure, Rackspace, etc.
In some circumstances, interacting with users via the database as a messaging system can protect them from issues with your server code, and server outages: if your server goes down, users will still be able to log in and interact with the database via client side code - they'll only lose access to server related functions.
I've added an issue to document the process for uploading to firebase after building a production version.
While there are some obvious limitations to using Horizon, it's incredibly convenient for quickly getting something working that 1) is online, public-facing, but secure (OAuth), and 2) provides a CRUD back-end very quickly with little work.
I've run into a bug or two so far, and the documentation isn't entirely up to snuff, but I can highly recommend Horizon for some use cases.
Specifically, Horizon is great out-of-the-box if you're creating an app where there's authenticated users who can do pretty much anything to entities owned by themselves, and where a client-side interface suffices. A todo app, or journalling app would be a typical example: the user can do whatever he pleases with his own todos/journal-entries, provided that he's authenticated.
Any greater complexity server-side probably needs an Express app (or Hapi, Koa, etc.), but there's really quite a lot you can do with a 'vanilla' Horizon server.
I am starting on a big SPA project. react+horizon+rethinkdb seem ideal for the read-only parts, but i worried about how to integrate some business logic which will require relational transactions on the backend
Got to check out your stuff - I've heard about vue.js but am not very familiar.
Sorry, but with those many dependencies, I could hardly call that minimal.
That said, leveraging Browserify, Bubleify[0] and Ramda[1] alone can get you pretty far in a seriously maintainable way with modern code, which is super nice: keeps compile times stupid quick and reduces some of the cognitive overhead (and possible maintenance drama) that too many third-party deps introduce.
There's a balance to be struck here, and it's a hard problem, I think.
For me, a minimal stack is just an HTML file(possible with a JS file as well) that loads React and Firebase via CDN, and then relies on browser's shipped ES6 capabilities to write code.
But in that sense I might be trolling here since nobody actually does that :)
And, only React, ReactDom and Firebase (which has to be required in the page html, unfortunately, due to Firebase issues) actually ship down to th client
While I can appreciate the benefit of keeping your entire codebase small (especially the bits that aren't yours), I'm not entirely certain of the wisdom of trying to build a react/es6/less/sass transpiling development environment with as few external dependencies as possible :)
babel-core, babel-loader, babel-polyfill, babel-preset-es2015 and babel-preset-react can be considered one dependency (it's babel...).
react and react-dom are another.
webpack, the dev server, and 3 webpack plugins can be considered a 3rd.
That's 3 "real" dependencies. If that's a lot, then i'd love to see a "real" minimal setup.
Just because javascript dependencies tend to take the unix philosophy to the extreme doesn't mean that each of those should be treated equally.
IMO JS hits all of the points of the unix philosophy:
1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new "features".
2. Expect the output of every program to become the input to another, as yet unknown, program. Don't clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don't insist on interactive input.
3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don't hesitate to throw away the clumsy parts and rebuild them.
4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you've finished using them.
Following that, babel reducing its "main" code down to a "useless on it's own" core, and allowing all functionality via plugins fits perfectly in that ideal. Then there are "presets" which can be built on top of them to include many of those plugins as one dependency, and a package to polyfill things that can't be "compiled" at compile time (babel-polyfill).
If i don't care about optimization, i can just throw everything in there and it'll work. If i want to cut down on the size, i can look at my target browsers and drop things (like babel-polyfill, or in some cases even most of the plugins from the babel-preset-es2015), and can install and run only what is needed.
it also makes writing new features into something like babel simple as hell, you can do it in a 10 line plugin. That makes it extremely simple to avoid bloating other plugins with options/features and instead encourages new plugins that do what the option/feature wanted.
/pubic/
output directory. Put your assets in here next to the compiled js and css.
I have four of these little repos now, all forked from each other, all with that spelling mistake, no doubt.
[0] - https://www.firebase.com/docs/security/quickstart.html
"By default, your app has rules which grants every request full read and write permissions to your database"
I've been using Firebase a while, and so I didn't fully think through the experience for users unfamiliar with firebase.
By necessity, this repo use of firebase is somewhat opinionated. I intend to add comments and docs to explain the architecture and how to set it up to work with different kinds of persistent data (ie - shared and public data as well as user related docs). And, of course, to set up secure separate docs for different users.
It's intended for static hosting, where there is no server-side rendering (much of the point of firebase). At the moment it just does concatenation and minification, but the files are rendered on the client.
This isn't ideal, obviously - it's still unclear to me whether Google successfully crawls ajax sites. I would like to add build-time rendering, but it's of debatable value for static sites, since obviously, it can't be dynamically generated.
The hack for now would be to hard code 'content' into the React render target `<div>`, so that it lands immediately.