Production app viability

[alterx]

I'm currently developing an application that will allow the visually impaired to get a notification when they arrive to their bus stop and I'd love to use Hoodie since mobile internet connections are flaky and we don't want to loose the ability to provide a good user experience to people that will rely on this app.

In order to achieve this we need to create:

1. Global, publicly available routes (basically lists of bus stops). These routes can only be modified by administrative users via a CRUD UI.
2. Public user accounts in which people can store their favorite routes, we want these to be available offline for sure.

We don't expect a lot of users initially so we can afford some experimentation with the technologies and, to be honest, I'd rather use Hoodie and fix some hiccups than build my own sync engine.

So,

1. Do you think this is feasible with Hoodie in its current state?
2. Do you think there will be any issues scaling up? Also, what are the hardware requirements to run a Hoodie app + CouchDB reliably? I've seen a couple of related questions but I can't seem to find any numbers.
3. I've seen that there's a plugin system in the making (there's even an open PR) Is there any ETA on that? I know that you can extend the functionality by adding a module constructed as a hapi plugin to the path hoodie/server but what if I want to add multiple "plugins"?
4. Do you have any idea of what's the max amount of users we can support per couchDB instance? (I know this is a tricky question to answer, but I'd thought you guys would have an idea from your experience with minutes.io)

Thanks in advance (and sorry if this is not the right place to ask these kind of questions)

[gr2m]

Hey @alterx, welcome to Hoodie :)

I'm currently developing an application that will allow the visually impaired to get a notification when they arrive to their bus stop and I'd love to use Hoodie since mobile internet connections are flaky and we don't want to loose the ability to provide a good user experience to people that will rely on this app.

This sounds like a great project!

I’ve one technical question about "the visually impaired get a notification when they arrive to their bus stop": I assume you want to app to be able to run in the background than? You might need a native app for this. Maybe Service Worker can do that already, but that would limit you to Android devices at this point. Hoodie can be used for native apps as long as you use web technologies, we don’t have native Java/Swift clients yet.

Global, publicly available routes

Defining public routes that expose read-only data from a database is possible with Hoodie today.

What we don’t yet have (but could work on right away) is a client API that would provide the same API as hoodie.store, but for custom databases. Our plan is something like this

const routesStore = hoodie.store.open('public-routes', {onlineOnly: true})
routesStore.findAll().then(renderPublicRoutes)

These routes can only be modified by administrative users via a CRUD UI.

The UI part would require some work. Ideally this would be possible directly trough the Hoodie admin dashboard but we are currently not working on it, we want to finish the plugin architecture first, then build the admin dashboard as a plugin.

For the time being, you could build a custom plugin for it with custom routes etc, but I’d need to have a look into it, I expect some bugs here and a few things that would still need to be implemented, but I’d be happy to provide guidance as needed.

Public user accounts in which people can store their favorite routes, we want these to be available offline for sure.

What do you mean with "public" user accounts? What is possible today is that every user has their own private store and they can store any data in it that will also work offline.

We don't expect a lot of users initially so we can afford some experimentation with the technologies

Great :)

I'd rather use Hoodie and fix some hiccups than build my own sync engine.

Good choice! I’ve been there, don’t.

In case Hoodie becomes to much of a barrier, you can still use PouchDB directly and build out your own backend. You can still use parts of Hoodie like only the account module for example, Hoodie’s architecture is very modular.

Do you think this is feasible with Hoodie in its current state?

I think it’s feasible. It’s definitely an app within the scope of Hoodie and the parts that are missing have already been thought about and can be worked on right away as far as I can tell right now.

Do you think there will be any issues scaling up? Also, what are the hardware requirements to run a Hoodie app + CouchDB reliably? I've seen a couple of related questions but I can't seem to find any numbers.

I don’t see scaling issues right now. What would be problematic is when you would need lots of data sharing, but it doesn’t look like it at this point. Also CouchDB 3, which is in the works, will resolve these problems, too.

In terms of Hardware requirements, that is a very good question and we should come up with a good answer and add it to our documentation :) The Hoodie app itself is basically just a hapi application, it runs everywhere, including read-only deployment targets like Heroku and now.

For CouchDB, let me ping @janl.

One thing you could check out is , does that help already?

I've seen that there's a plugin system in the making (there's even an open PR) Is there any ETA on that?

The plugin system itself is working, ETA could be as early as Monday. I need to clean up the pull request and add documentation, other than that it’s all done!

I know that you can extend the functionality by adding a module constructed as a hapi plugin to the path hoodie/server but what if I want to add multiple "plugins"?

A hapi plugin can load more hapi plugins, there is no limit in terms of how many routes you can add etc, the logic can be spread across multiple files, too.

Do you have any idea of what's the max amount of users we can support per couchDB instance? (I know this is a tricky question to answer, but I'd thought you guys would have an idea from your experience with minutes.io)

minutes.io runs smoothly with thousands of active users using one CouchDB instance.

Let us know if you have any further questions!

[alterx]

Hey, @gr2m , thanks for such a quick response.

I’ve one technical question about "the visually impaired get a notification when they arrive to their bus stop": I assume you want to app to be able to run in the background than? You might need a native app for this. Maybe Service Worker can do that already, but that would limit you to Android devices at this point. Hoodie can be used for native apps as long as you use web technologies, we don’t have native Java/Swift clients yet.

Yeah, we're going to be using either React-Native or Ionic and the native Geofencing features of iOS and Android. The main idea is to define a geofence around the bus stop and let the OS monitor it. Once, the geofence limit is breached we'll send a notification to the user.

What do you mean with "public" user accounts? What is possible today is that every user has their own private store and they can store any data in it that will also work offline.

Yeah, that's basically what I mean. By "public" user I mean any user that creates an account and uses the app.

Defining public routes that expose read-only data from a database is possible with Hoodie today.

So, for example, we could install the global-share plugin and do something like:

1. Create an administrative user and create all the publicly available bus routes.
2. Publish these routes using hoodie.store.findAll('event').publish();
3. In the app use hoodie.global.findAll('public-routes');, this should give us read-only data that every user in the system can access.
4. Then, individual users can use their own store hoodie.store.add('myroutes', route); to add routes to their favorite list and access them offline.

Did I miss something? Is that the proper way to define "public routes that expose read-only data from a database"?

Ideally this would be possible directly trough the Hoodie admin dashboard but we are currently not working on it, we want to finish the plugin architecture first, then build the admin dashboard as a plugin.

One problem I see regarding the global-share approach is that an user could create and publish fake bus routes. I guess the answer is this admin dashboard. Even if it's not being worked on I could get some inspiration out of it. Is there a way to see it working right now? The administrative accounts are created outside the hoodie account system, right?

It sounds like having the plugin system in place is the key to fix/implement most of the things we need for our project. Is this the PR I should be looking at?

[gr2m]

Is this the PR I should be looking at?

yes it is

we could install the global-share plugin

the global share plugin is deprecated. It’s from the old Hoodie and won’t work with the new one.

I guess the answer is this admin dashboard. Even if it's not being worked on I could get some inspiration out of it. Is there a way to see it working right now?

The current admin dashboard can be accessed at /hoodie/admin. The password needs to be passed as adminPassword option, see http://docs.hood.ie/en/latest/guides/configuration.html#options

The admin dashboard is currently an ember app and doesn’t do much. It was just a quick experiment, we like the ember community a lot, but might move away from ember to make it easier to contribute to. The main repository is here: https://github.com/hoodiehq/hoodie-admin

We also have a work-in-progress admin client: https://github.com/hoodiehq/hoodie-admin-client. It currently only has methods to manage accounts. For your use case, you need APIs to manage custom databases and data within them. The backend logic for that already exists, maybe a few routes might be missing. But overall I think extending the client API to let you manage databases / data is what you’ll need for a custom admin dashboard for your app.

Having an Hoodie admin client API to open databases is actually a similar requirement to adding and api to the Hoodie client which lets users open custom databases, like your public routes database

[alterx]

Hey @gr2m, I'd like to start working on the ability to define online-only, global collections (something like what you mentioned in this comment). I'd like to discuss implications and where to start. Hoodie is modular (and that's awesome!) but that also makes it harder to spot where to start.

I know I probably need to look at https://github.com/hoodiehq/hoodie-store-server-api and https://github.com/hoodiehq/pouchdb-hoodie-api for the server part (creating new online-only databases) and maybe here https://github.com/hoodiehq/hoodie-admin-client (?) in order to extend the admin module to support global collections in addition to accounts.

ps. I tried to get my slack invite but it looks like the site is down :(

[gr2m]

Hey Carlos, I’d be more than happy to get you going. Today is pretty packed for me but I’ll have time over the weekend.

Sorry for the slack issue, I’ll have to investigate this. Can you dm me your email address? https://twitter.com/gr2m

[alterx]

The slack thing also broke for https://github.com/storybooks/storybook so maybe re deploy it to now.sh (?)

Sure, there's no need to rush :)
My TW handle is https://twitter.com/__el_Negro