General discussions and questions about Hoodie
Repository used to collect general discussion topics
For all general Hoodie discussion and ideas that are not specific development tasks. If you have questions about Hoodie and don't know where to ask them, this is also a good place.
Continuing the discussion and providing updates as referenced:
I pushed an update to the social plugin to support Pocket configuration (not tested with the new Pocket yet):
inator/hoodie-plugin-social@28870a4
I'm getting ready to start work on support for social posting, so if any of you have any feedback on what's been done so far, please be sure to let me know. Thanks!
Issues that come to mind are tasks and workers interfering with each other.
It seems any XHR image requests made only execute when a running long poll finishes. I use AngularJs to load images like so: which creates a request when I assign a value to product.id sometime during app execution. The request for this image does not seem to finish till Hoodie's long poll finishes (See screenshot, all images load together after 25s).
I then modified hoodie-server/node_modules/hoodie/src/lib/store/remote.js to change the timeout to 11s, which resulted in the screenshot below (all images load together after 11s).
This seems to affect only Safari on iOS (I tested with iOS 7.0.3).
I know that this is not precisely Hoodie related (because it should affect all long poll requests) but any help would be appreciated.
Will update this as I get more information.
Had a discussion with @janl & @caolan and thought about writing down our ideas for later. Core idea is that scheduling a task means that the task object gets re-created with passed properties at the given schedule
// run task on Friday afternoon
hoodie.schedule.add('email', taskProperties, {
on: 'Friday afternoon'
});
// run task every Monday at 6am
hoodie.schedule('email').add(taskProperties, {
every: 'monday at 6am'
});
// find all scheduled tasks
hoodie.schedule.findAll()How.
We need a single document that tracks Hoodie’s roadmap. This is it. @janl is responsible.
The version numbers here correspond to the entire Hoodie system releases. Individual components have their own version numbers.
Hoodie’s current version: 0.2.0.
The Roadmap:
hoodie-plugin-users:
This is a little bit more detailed explanation of a use case we are working on so that I can illustrate exactly what kind of feature we are after. We are building a Hoodie app that has a few users (short lived). To illustrate, think of some kind of "webshop".
So you have a product catalog that the users can browse (they don't need to be logged-in) and they can place orders (for this they do). Specifically the product catalog (and perhaps also the orders) documents are not tied to the user. Ideally, I would like to be able to load a list of products to show this in the catalog. I was wondering what would be the best practice to do this. After a quick discussion with @janl, we came up with 2 options:
Personally, I'm a bit in a favor of option 2.
If we take another example, imagine some kind of "timeline" in Facebook. All users would post some kind of updates that should be visible by all users (ignoring privacy settings complications here for a minute). What would be the right place to store such docs (the updates)...?
I'm not quite sure if Hoodie has some kind of features to actively setup CouchDB-style replication between a user DB and a "standalone" DB, but that would be handy. A replication is just another kind of document, so that should be doable.
Imagine we commit a fix to hoodie-plugin-api. What needs to be done that the next user that does hoodie new myapp gets that fix?
We should define a process by which an update in a lower-dependecy module propagates to a new release of the high-level modules that are referenced in the user’s apps (e.g. my-frirst-hoodie, hoodie-server and the plugins.
How?
The idea is to have several templates you can choose from when you create a new hoodie app in the cli.
hoodie new appName
which template would you like to get:
(1) my-first-hoodie
(2) boilerplate
(3) boilerplate with bootstrap
(4) boilerplate + OO-CSS + res. CSS
choose: 2Later (maybe for 1.0.0., we could make custom builds).
// @svnlto and I already talked about that.
Your thoughts?
This is to define how we specify the versioning of Hoodie the project. Hoodie consists of many independent projects each with their own repository, version numbers and release schedule. In order to have a better communicable roadmap, we should have overarching version numbers for the entire project.
The idea now is to have Hoodie version numbers that incorporate all sub-projects on a specific version number. For example, Hoodie 3.5.0 would depend on hoodie-server 4.15.2 and hoodie-plugin-users 2.6.5 and Hoodie 4.0.0 would depend on hoodie-server 5.1.2 and hoodie-plugin-users 3.3.1 (omitting other dependencies for brevity).
To make things transparent across all repositories, we tag all individual issues with a label that expresses which Hoodie release it belongs to. The labels are of the form release-x.y.z. That way, we can use Ubersicht to see which issues belong to which release.
The de-facto enforcement of mapping sub-projects to hoodie versions would happen via hoodie-cli which can specify which version of my-first-hoodie a project will be based on which in turn specifies in its package.json file which versions of hoodie-server and so on are part of an installation.
A word on semantic versioning: we will be following the guide at http://semver-ftw.org — Most importantly, we don’t use version numbers for marketing (except for Hoodie 1.0.0 :) or specifying the stability of Hoodie or a sub-project and we will be following http://nodejs.org/api/documentation.html#documentation_stability_index there (again, except for 1.0.0 which will be our first and only “first, complete stable” release). Every version from then on follows semver-ftw strictly.
Anyhoo.
drops mic
There are currently over 300 open issues across repos and more are opened every day. I wondered if it makes sense to put a triaging process in place, so that we can get them structured and closed/fixed faster.
(As always) the Angular team has something in place already and it's applicable to Hoodie with a few adaptions.
https://github.com/angular/angular.js/blob/master/TRIAGING.md
Thoughts, suggestions?
Hoodie should collect all sorts of metrics and make them available nicely.
I have a requirement of implementing a robust chat system. I'm using a Hoodie plugin for this (latency is not an issue for this use-case).
The idea is that I create a chatroom, then use the plugin to add a copy the chatroom object into every user's database (and add it to any user who signs up after it was created).
Each chatroom object has a members list, an array of Hoodie usernames indicating membership. If a user joins or leaves a chatroom, the user's name is added to or removed from the members list, and the chatroom object is updated in all user's databases.
The problem is, I can't figure out how to listen to chatroom updated events in plugin code on the server (in worker.js), or how to send updated objects to the server from the hoodie API. Everything I try either fails or seems to result in an infinite loop.
I'm not sure how to implement this, and I'm not sure if this is the best approach to this problem. Any advice will be appreciated.
cc @peetersn
Somehow related to my previous issue #43
I would love to discuss the meaning and concept for a Hoodie account and user.
Currently in Hoodie the account and the user are basically handled as the same thing, or am I wrong here? At least the distinction between a Hoodie account and user is not very clear to me.
From the mental model in my head, I would say:
This definitely goes beyond the simple method name change, but if you have any thoughts on that, I'd be glad to discuss that more and see how the concept applies to different apps (with different user management, account management requirements).
This relates to a question @janl asked here: #4 (comment)
I think it would be great if the plugins API would allow for the addition of _api routes and handlers. Jan may have had that in mind, but I thought I'd toss it out for a more explicit discussion. Is it do-able?
Right now Hoodie takes over your entire CouchDB. This is probably fine for simple deployments, but better I think would be an optional per app/request database prefix so Hoodie apps create databases like /myapp/app, /myapp/plugins, /myapp/users/whomever, etc.
Running a separate CouchDB instance per app is wasteful of resources. While Docker/LXC is always an option, it shouldn't be the only one. I could imagine a multi-tenant Hoodie app where I have a free/trial tier, and I wouldn't necessarily want to spin up separate instances per user/resource bucket.
My understanding is that lots of PAAS platforms provision single database services for all apps. So it'd be useful to let apps set their own prefix to run on the single CouchDB instance/cluster.
Also, I might be developing a multi-tenant app which I'd like to sell to organizations and teams. In that case, it'd make sense to create separate namespaces per request, keyed off of the subdomain, so each team would have its own distinct databases.
the unauthenticated state is a big pain in the ass. It's great that we have it, I think it's a great feature, but it should not be the default state of the app.
moving @gr2m issue over here:
frontend: updatedAt: '2013-12-09T16:09:34.138Z'
backend: '$processedAt': '2013-12-09T17:15:00+01:00'
In the frontend, we you the default input of JSON.stringify(properties). How is it being created in the backend? I don't think there are any problems with this, I even prefer the backend timestamp format, but let's discuss that
instead of syncing all user data
Hi,
CouchDB has great support for attachments, is that something that we can leverage in Hoodie? We have a use case where we would like to upload some attachments (pictures) from the UI and store them in CouchDB. I saw that the email plugin has some kind of support. Would you recommend to use the same approach for normal attachments?
This is about the names and concepts for the hoodie account.
I noticed, that every time I do something with HOOHoodie it takes me some time to get the difference between signIn and signUp. The methods just look so similar and even the signature is the same. Others on Twitter confirmed that it was hard to distinguish, also UX research confirms that:
http://uxmovement.com/buttons/why-sign-up-and-sign-in-button-labels-confuse-users/
So I'd like to change it for the iOS SDK (even if it's just for my own sanity ;-) also it's still pretty safe to change the API there).
But I would love to discuss better alternatives here too and get feedback from some others. So far suggestions are:
Any thoughts / suggestions on that?
Hi team Hoodie (:
inspired by some great experiences with Hoodie, the team and the community, I am thinking a lot about what one can create with it. Hoodie is about "very fast app development" and I keep wondering what kind of apps are possible with its approach (and which aren't).
One feature of modern apps that is growing in popularity and adoption is the ability to manage different versions of a piece of data. An example would be Google Docs, which is creating a "Revision History" by creation a revision on every save, but also Dropbox (file-based).
@gr2m explained to me that CouchDBs revisions could not be used for reliable versioning. Also, the API, e.g. hoodie.store.find does not seem to anticipate or in any way handle this issue. Hence, I would like to start a discussion whether Hoodie wants to support versioning and if so, how the API should look like.
To foster the discussion, I'd like to present a thought experiment:
If Hoodie (core) decided not to handle versioning, could one create a versioning system on the client-side? To accomplish this, one might handle changes to the data in the app and provide hoodie with a big array containing all versions. Hence, whenever your app would consider something a new version, that new object would be pushed onto that array and hoodie.start.update would be called with that array.
In my opinion, this creates a layer of data management between the app and Hoodie. This was precisely what I would like to avoid and the main reason I would use Hoodie. It does not seem like a good option to me.
Below is my "Dreamcode" from a Frontend Dev perspective. It's just an idea, it might not even be possible, but I hope it is at least worth discussing.
hoodie.store.find currently takes a type and an id argument. I propose a third argument version which is an int. It defaults to 0, meaning the most recent version. 1 would mean second last version and so on.
localStore.save could implement this by increasing this version count by one.
I have no idea how that would be implemented on the backend or with CouchDB, I hope someone can chime in on that.
I hope my feedback is relevant and I would be happy to help moving this discussion and possibly an implementation forward.
Best,
David
It would be nice to have auto-publish set up for all of hoodie's projects so we should fetch the latest version directly from npm instead of github.
Travis provides a script for that: http://docs.travis-ci.com/user/deployment/npm/
I'd like to be able to attach files to documents. While storing binary data in the database isn't the greatest idea, I'm not sure of a more elegant solution for offline-first development. If I store a profile pic with my user account, an online-first service might store it in a CDN, but something like Hoodie would probably benefit from an API for storing and syncing document attachments. Maybe something like:
How should we handle the case when Hoodie-internal data structures change?
@gr2m should have discussion notes for this.
Hello peoples,
First sorry, my english is pessimous! I hope that can understand my questions :)
I'm user Rails, but knows Hoodie and I love this :)
My question: Hoodie is very simple, enough to call signUp to register user. In rails, we have a combination key to security a form send data. Server also accept post, (example) that have a key generated random in form. This is ensures that direct call don't work.
In hoodie, if user acess a instance variable via console, he can execute any methods? This does not allow an attack DDOS? Our massive register (a loop of stored objects)?
Use-case for detecting idle users on the server:
Imagine a chat application that should notify active users if a participant has become idle, or even disconnected from the chat by way of not using the explicit signOut() method (e.g. close tab, close browser, put computer to sleep, leave wifi/cell area with the phone etc.)
Use-case for detecting idle users on the client:
Imagine a user opening an app in a browser tab and leaving it idle for longer than the session timeout. How can we detect this reliably in the client to a) inform the user about the situation and b) do the right thing* for the data storage part.
(* this might be explicitly keeping and storing for sync any existing data, or explicitly discarding any existing data, because it was only valid in the previous session context)
Technical proposal to solve server side detection:
Approach 1. is very simple to do and can be done today, but it creates a secondary channel for session live-ness, which uses extra network requests. By and large this shouldn’t be a big problem, but this can be improved by approach 2. that just piggy-backs on the already existing normal requests. However this is a little more work and requires a new version of hoodie-server. The main LRU cache logic can be re-used in either implementation.
Technical proposal to solve client side detection: TBD cc @espy @svnlto @gr2m.
I'm building an app where I need to clear data from the server occasionally (part of the business logic).
If a user who was previously using the application attempts to connect back to the server after the server has been wiped, the system is in an inconsistent state, with the user logged in on the user's device but with no corresponding user on the server.
Is there any way to check if the user exists on the server without signing out and signing in again?
Moved from: hoodiehq/hoodie-server#170
it should be super simple to whip up one or more Hoodie instances that then run in isolation on some solo, or shared infrastructure.
Naïvely, this could be done on Docker with a bit of plumbing and one of the many build-your-own PaaS projects on top of lxc/Docker.
Of course Docker is new and lxc doesn’t have the same isolation guarantees that hypervised virtualisation (aka Zen / EC2) has but it might be good enough to get started.
All this should be as end-user friendly as possible.
It would be nice to have a Pocket plugin that allows publishing to one or more remote Hoodie Hosting instances.
How should we handle the case when user’s data exceeds the storage capabilities of the browser?
Examples are gmail or flickr.
There are possibly multiple ways to deal with this, depending on what kind of data is used (large binaries vs. lots of email).
Image a plugin that not only extends Hoodie, but also defines its own user interface bits. Once could load the resources via XHR, and serve them over the web hook API, but that’s clumsy.
For pocket we already allow serving of all sorts of frontend assets from a folder.
We could add ./hoodie.pluginname/ analogous to ./hoodie.pluginname.js to be the document root for plugin assets and the server that over /_api/_plugins/pluginname/_assets, or something of that vein.
This is a follow up for hoodiehq/hoodie#24, hoodiehq/hoodie#55, hoodiehq/hoodie#242, hoodiehq/hoodie#321, hoodiehq/hoodie#327, hoodiehq/hoodie#328, hoodiehq/hoodie#330, hoodiehq-archive/documentation#33
account.usernameaccount.username is setaccount.authenticate()If the user's data is being synced, account.authenticate() checks if the
user has a valid session.
I'd suggest to remove this method and use it internally only.
account.signUp(username, password)account.anonymousSignUp()Starts to sync user's data, e.g. to prevent data loss. account.anonymousSignUp
is called automatically the first time a task is created without the user's data
being synchronized, as sync is required for tasks to work.
I'd suggest to remove this method and use it internally only.
account.signIn(username, password, options)account.signOut(options)account.request(type, path, options)Just an alias method for hoodie.request. We should remove this.
I'd suggest to remove this method and use it internally only.
account.fetch(username)Fetches the _users doc
I'd suggest to remove this method and use it internally only.
account.changePassword(currentPassword, newPassword)account.resetPassword(username)account.checkPasswordReset()Checks for an existing password reset request.
I'd suggest to remove this method and use it internally only.
account.changeUsername(currentPassword, newUsername)account.destroy()should require current password #55
account.hasAccount()returns true if the user's data is being synced
This method caused quite some confusion and should be renamed / removed
account.hasAnonymousAccount()This method caused quite some confusion and should be renamed / removed
account.db()returns the user's database name
I'd suggest to remove this method and use it internally only.
signup (username)signup:anonymousTriggered when anonynmousSignUp called, either explicietly or internally.
The event is used in the hoodie.remote module to start sync.
signin:anonymous (username)Triggered when user has an anonymous account and has been signed in internally.
The event is used in the hoodie.remote module to start sync.
movedataTriggered when account.signIn called with moveData: true.
The event is used in the hoodie.store module to move
local data to new account.
reauthenticated (newUsername)Triggered when hoodie.signIn called with current username and sign in succeeded.
signin (newUsername, newHoodieId, options)Triggered when hoodie.signIn call succeeded (and not called with silent: true)
changepasswordTriggered when hoodie.changePassword call succeeded (and not called with silent: true)
resetpasswordTriggered when hoodie.resetPassword call succeeded (and not called with silent: true)
error:passwordreset (error, username)Triggered when password reset failed for passed username
changeusername (newUsername)Triggered when hoodie.changeUsername call succeeded (and not called with silent: true)
error:unauthenticatedTriggered when hoodie.authenticate failed for an account that is syncing data,
either called explicitely or internally, e.g. when sync requests from the
hoodie.remote module returned a 4xx response error.
passwordreset (username)signup (username)cleanupTriggered on account.signIn to cleanup current local data, or in account.signOut.
The cleanup event is always triggered, even if the methods get called with silent:true,
so that other modules and plugins can reset their local data / settings. Currently the
hoodie.store and hoodie.id modules depend on this event.
signout (username)We are exposing internal technical details instead of providing the features
a user would expect. While methods like account.signUp / signIn / signOut
have been dreamed up™ months before the implementation, other methods
are the result of how we implemented them. This goes against our own maxim
of dream driven development, as it exposes internal implementations instead
of serving user's intents.
The methods in question are:
account.authenticateaccount.anonymousSignUpaccount.requestaccount.fetchaccount.checkPasswordResetaccount.hasAccountaccount.hasAnonymousAccountaccount.dbI'd suggest to remove them altogether form the public API and
use them internally only.
account.destroy should require the current passwordaccount.username should instead be a method: hoodie.getUsername()account.resetPassword should send a token, not the new passwordaccount.isSignedIn()App developers want to know if a user is signed in or not. We don't provide
a simple method for that, so they looked for alternatives and got confused
of whether to use account.authenticate() and account.hasAccount().
The reason I didn't implement account.isSignedIn() is that I wanted to
avoid to return true while the user's session is unauthenticated. But after
working with Hoodie on several projects for some time now, I changed my mind:
The state of being signed in but unauthenticated should be treated as error
that might occur at any point for signed in users, the concern should be
separated from whether a user is signed in or not.
So my tl;dr suggestion: let's add account.isSignedIn() and make it return
true or false. And let's leave unauthenticated to the events section,
it should not confuse first-time Hoodie users at first sight.
account.confirm(options)All users that sign up for an account get confirmed automatically today.
We want to allow for alternative options, including an email confirmation
workflow. For that we need an account.confirm(options) method, options
being token: "secrettokenhere", username: "usernamehere". username could
be optional and the current username could be used.
The same method could be used to confirm (additional) email addresses belonging
to one user account, e.g. for apps that allow to send emails with the ability
to set the FROM property.
See also hoodiehq/hoodie#24
account.checkAvailability(username)Allows to check whether a username is still available or not. Method should
resolve if yes, otherwise (or in case of request error) reject.
See also hoodiehq/hoodie#327
Data like name or address should be allowed to be passed to account.signUp,
and additional methods should be added to get / set custom data.
Besides data that is changeable by the user, it should also be possible
to set read-only user data, like plan.
See also hoodiehq/hoodie#328, hoodiehq/hoodie#220, hoodiehq/hoodie#175
Moved from hoodiehq/hoodie-server#172
Pushing notifications to client using MQTT libraries (http://mqtt.org/wiki/doku.php/libraries) would be a good enhancement.
Perhaps this can be implemented as a plugin but having as part of hoodie-server would add value.
Hello,
Just wanted to get some advice related to the _id field that is generated by Hoodie. Imagine that we have a task object, the document would look like:
{
"_id" : "task/12345",
"_rev", "1-c60608ef791f7859dae4b1e4dbab485e"
"title": "Try out hoodie today",
"type": "task"
}
Imagine now a scenario where we want to replicate these task documents from an external CouchDB where we have a different pattern for the ID: is it possible to change the "id" field in Hoodie to use another format? (e.g. "_id" : "COMPANY_CODE:task:12345").
If Hoodie mandates this ID structure ("task/12345"), then that means that you would have to write some code that recreates new object based on the fields of the original DB to something that Hoodie can work with (some kind of manual replication).
PS: Would update handlers in CouchDB be of any help here?
This would be nice. What do we need?
Imagine an app that has users, admins and app-admins. Users and app-admins we’ve got covered with regular users and pocket, but what about admins that need to be able to do things that regular users are not allowed to, but are also not as powerful as app-admins that have essentially raw access to all CouchDB?
Jan and I discussed the idea of sort pre-milestones for the 1.0.0. launch.
We tried to look at the high-level issues and sort them by related topics, including dependencies.
When we're done, we'll sort all listed issues to the pre-milestones and define deadlines.
Long term:
- define processes – ALL
- while you work on other milestones, keep notes on your process
Done / almost done:
- Finalize Plugin API – C
- mailing lists for plugin & app authors – J
- Hoodie versioning – C, A, G, J, S (done, Jan to write up)
0.1.0:
- Public Shares – S
0.2.0
- Pocket – O, S, A
0.3.0
- Payments – G, S, J
0.4.0
- User Registration Flow – G, S, J
0.5.0
- Security – C, S, A
0.6.0
- try.hood.ie – G, J, L, O, S, A
- Hoodie Virtual Machines – C, J
0.7.0
- My First Hoodie Experience - A, O
- First Plugin Experience – A, O
0.8.0
- Comprehensive CI – J
0.9.0
- PouchDB – C, G, S
0.10.0
- Website Relaunch – O, A, L
- Docs Launch: translations, tutorials – O, A, G
- 5 minute screencast – O, A, L
- Deployments – J
- Proper Press Release – L, O, G, J
0.11.0
- contributor onboarding – L, S, O, G, A, J
- lead up blog post series – ALL
- merch – A, L, O, J, G
- Events (incl. launch party) – L, J, O, G
What do you think about the structure?
Are the numbers reasonable?
Feel free to add your thoughts!
THANKS!
While working on Hoodie-iOS, @gr2m helped me a lot in getting to know the Hoodie Server API. But for reference and for people who might want to port Hoodie to other platforms, like Android, an official API documentation would help tremendously.
Do you already have a place for the API documentation? Or any ideas how you want to set that up? I'd be happy to help and contribute what I know so far.
The use-case here is that data might come from other node apps, that can’t easily be turned into Hoodie plugins. It’s be nice to make hoodie.database available to these apps via a node module (and even other language modules are possible), so they can import data into Hoodie and have the CouchDB documents have the right format and everything.
Maybe this is already possible tin hoodie-plugin-api today and I just haven’t looked hard enough, but IIRC it is all a bit too entangled to be used standalone.
Hello team Hoodie (:
I wanted to give you some feedback on my experience with getting started.
First of all the website really is excellent for the bigger scope of the project and doing the first few steps, but once I started digging deeper, or running into problems it turned out that the information is spreaded across too many locations and fragmented.
You already realized that it's hard to stay on top of issues across all the repositories and that's why Ubersicht came to life. While it's without question a super awesome tool, it's focused more on team members, or people who are already into hoodie.
It's totally reasonable, even necessary, to have that many repositories. I just couldn't find one central description of which module does what (I know this might seems obvious, but still), how they matter to me as a user, how I interact with them, where to look for existing issues, create new ones and which readmes to read.
Which leads me right to the next point – Readmes. Many of the repositories have their own readme, beginning with a general introduction to hoodie. It doesn't seem like the general intros are synced between the repos or the website which makes it hard to keep them up to date and as a reader I get the impression that I've already read them. That way I might skip over essential information. @janl already started a discussion about versioning in #17 where he states that even though the modules are versioned independently they are associated with a certain hoodie release.
I propose to have one central Readme that contains examples, troubleshooting etc. that matter to the user, together with the submodule description I mentioned earlier (This should also be the one that is distributed with my-first-hoodie). The specific repos' readmes should only contain information relevant for development and maintenance.
I know you don't want to use version numbers for marketing and that's a good thing imho. Nonetheless it would benefit developers to communicate releases transparently (also please employ pre-release flags if something is unstable, untested or super new), so they can troubleshoot better, and ultimately report bugs that are specific to a certain version. Changelogs would be awesome, too. I guess the Angular team already nailed that with their commit message conventions and automatic changelog generation.
As discussed in hoodiehq/hoodie#212 and #31 of course the project would benefit from a source generated documentation for both the frontend and server API as well as more in depth and profound deployment instructions.
I hope my feedback is relevant to you and I'd love to help fixing stuff.
Best,
Stephan
I'd like to validate documents submitted to the store, as I'm vaguely worried someone might get into the console and store a bunch of junk data. While I can't prevent that from happening locally, I'd like to prevent someone from stuffing my server with junk, and validations would be a good sanity check for my code. Maybe something like:
hoodie.validate("todo", function() {
throw({forbidden: "No way"});
});
Initially these functions might be triggered on local storage changes, but ultimately stored in a Hoodie-specific design doc in a local Pouch and synced to the server later. Ideally these validations could be stored server-side as well. I suppose if the design doc is bootstrapped from the client, it will sync to the server on signup.
As Hoodie’s base infrastructure gets better, we should be providing components for common UI tasks.
The motivation behind the plugin is to provide a better experience to an app that is used by multiple users on the same device. I'd like to provide an experience similar to the Mac/Windows welcome screen:
And probably also an account switcher UI, similar to what Google provides:
My big question: how would I call such a thing? @tenmilestereo suggested hoodie.profiles which I like the most so far. I also thought about hoodie.accounts, but that might be easily confused with the core hoodie.account API
For my specific use case I came of with that dream API
// returns the array of locally used accounts
hoodie.profiles()
// manually add a new profile
hoodie.profiles.add('[email protected]', optionalExtraProperties)
// the idea is that new profiles get added and updated automatically by hooking into the `signin` / `signout` events
// remove a profile, returns true / false depending on whether the user exists
hoodie.profiles.remove('[email protected]')
// update a profile, returns true / false depending on whether the user exists
hoodie.profiles.update('[email protected]', changedProperties)
// convenience method. Returns the object of the last active user or undefined if there is none
hoodie.profile.lastActive()What you think?
In some cases, data encryption on both client and server is required. For example in mesh-network setup, where the nodes are physically accessible and could be taken and looked into from outside.
I think an encryption layer could be added as a plugin. In the frontend, it would expose the same API as hoodie.store. For example
// add a new todo object
hoodie.encryptedStore.add('todo', {title: 'remember that'})
// internally, the method encrypts the data and then persists it using `hoodie.store.add('todo', encryptedObject)`The logic to encrypt/decrypt object must exist on the server as well. For example, when an encrypted task object of type order gets triggered, the order plugin receives the encrypted data, decrypts it, executes it, updates it states, encrypts the new object, and updates the encrypted object in the user's database.
Does that make sense so far? I'm not an encryption expert, so I can't make good suggestions on what encryption algorithms to use.
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
Django
The Web framework for perfectionists with deadlines.
Laravel
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
Microsoft
Open source projects and samples from Microsoft.
Google
Google ❤️ Open Source for everyone.
Alibaba
Alibaba Open Source for everyone
D3
Data-Driven Documents codes.
Tencent
China tencent open source team.