Architecture

[shrunyan]

After working through some architecture with the search process I'm going to layout my viewpoint on the overall architecture before I get to far. Want to make sure there is some discussion about each aspect.

This can also be a good starting point for putting together a milestone checklist.

Client

I'm a huge fan of the unidirectional front-end architectures, e.g. flux. A implementation of flux is most likely over kill but using common components of that stack could be helpful in reasoning about the application.

Router

Currently the codebase uses page.js for routing. This is a great choice and should continue to serve the needs for the application.

State

I think redux would be a great solution for handling runtime state. We could also write middleware to sync data changes to firebase.

Views

React is quickly becoming the defacto for rendering UI. I'm personally a fan of riot. Consolidating around a common community solution can be a good option so other contributors can have a baseline for understanding the UI.

As well as there already seems to be a well written implementation of Material design in react. material-ui

Database

Firebase will serve as the single source of truth for the application. This is a good choice because it's flexible enough to allow using for catalog data, user data and queued requests. It also removes the details of syncing data between the data store, client and server. Due to firebases free tier option it will also work nicely for allowing users to fork and setup all the requirements for hosting their own instance. These can help reduce resource needs of the main http://flyleaf.co instance.

Workers

Workers will be used for managing data source imports and search indexes.

Data Sources

All comic data sources need a source importer written for them. Their duty will be to pull data from a data source and map it to flyleaf data models. This will ensure all data entering flyleaf will be consistent and reliable. Ideally these importers will be scheduled to run. Potential as cron jobs, this will depend upon the hosting environment.

e.g. MangaEden

Search

By using a worker to manage an Elasticsearch instance we will be able to get efficient content queries while keeping firebase as the single source of truth for data.

User Authentication

Users will need to be able to authenticate an account, this way we can persist their viewing meta data. Potential this could be handle with an third party oauth mechanism, e.g twitter open auth. This could also be useful from a long term perspective if latter we want to integrate social features.

The existing client side auth, here, is solid open auth might be better suited as a long term goal.

API

At the moment I don't see a need for an API, since most data can be persisted to firebase and this logic can exist in the client code base.

[shrunyan]

@aerze here are my initial thoughts. I've started on the search indexing workers if you want to get an idea for what that code looks like.

I think we'll be able to separate the server side changes from client changes, since client data is loaded from firebase. It'll be able to act as our api broker.

[aerze]

@shrunyan I see what you mean by API broker and I like it, though that part where you're deleting the node, you can probably just update the same node after the search is done, that way the client can listen in on the same node.

Client

I haven't used redux or Riot and I'm partial to my home-brewed renderer, but I understand that for wider adoption we should using something more common.

For client architecture I would agree with:

• page.js
• redux
• riot.js

(I'm especially interested in redux because I don't get how it fits in yet.)

Database

Firebase is great for everything so far, but I'm still curious about how it handles offline and if that's something we want to build into flyleaf at all (eg. saving books for later).

Workers

What you planned is exactly what I wanted but never knew how to do.

User Auth

I wonder if we can take advantage of the oAuth built into firebase.

[shrunyan]

I'm partial to my home-brewed renderer

I'm cool with using your home brew. Would give me an opportunity to dig into DOM perf a bit and re-enforces some concepts. Let's discuss that one in person. It'll be easier to cover pros/cons.

I'm especially interested in redux because I don't get how it fits in yet.

redux is fantastic! it makes reasoning about the state of your application so much easier. Especially understanding where data mutations occur. Also probably best explained in person.

Firebase is great for everything so far, but I'm still curious about how it handles offline

I actually had not considered offline yet, which would be super rad for offline reading. With offline we should look into service workers since that is the standard for offline now. I think that will mesh nicely with firebase.

workers

I'm still pretty new to using workers. If you want we can discuss those in person.

user auth

I think we can either do basic user auth with firebase or use a open auth source. With open auth we'd still use firebase to persist access tokens. The intent of open auth is that we don't maintain or manage user access data, e.g. email and password. We leave authentication to the external service and store an encrypted answer in a cookie. Then we can validated the cookie data against our stored access token on a new session.

That being said, I think initially basic auth with firebase will serve our needs. An open auth integration could be considered if we get to social sharing features.