I am quite sure that I am not the first person on the planet trying to implement the following, but I am sure that I am not able to find a good guide how to do it.
Our node backend is setup quite like a MVC to say so.
View = Express Server offering our api
Controller = Library, a set of controller functions to manage our data
Model = Our mysql database, it's Javascript DAO respectively (since our usecase is quite unique we need to write own DAO's and can not go let's say for js-data.
The challenge we face now, is:
As a developer, I want to keep our library clean from overhead for developers.
On the other side, as a database administrator I clearly want to know who did what modification and so on
Until now I tried to keep the 'user' object out of the library, since I do not want all controller functions to look like
function ctrl(param1, param2, param..., user)
Going for this would mean, we have to pass around User objects all the time, which would make it a pain to code inside the libraries.
On the other hand, I can not find any other approach in node/express to somehow get knowledge about the user without passing it (since we do not really have sessions, at least not yet in our code).
TL:DR; I do want to action log all database modifications, but do not want to pass around a User object all the time.
Is there any known approach for that challenge which does scale and is 'best practice'?
Thanks in advance
Related
I am a compete beginner to AWS and amplify, but what I am trying to do seems it should be fairly simple.
I have managed to set up front-end react access to read/write to amplify GraphQL database. What I want however, is only people with an access code to be able to read/write from the database.
In short, I want a form on a page to be filled out only if the person knows/has an access code. I don't want to go through the hassle of creating accounts and setting up authentication, because security does not need to be person specific and high. I imagine the validation of the access code is similar to validating a promotion code (a list of possible promotion codes is available on the database and it only gets validated if it matches one of them).
This should be done on the server-side. If anyone knows what is needed and if they know of any resources on how to do it please let me know.
Any advice on how to approach this? Many thanks.
I've tried researching if I should use nodejs or lambda but don't really see how this would work. Ideally somehow just adding a layer of validation ontop of the front end react reading/writing to the database.
I am learning to make a website with nodejsn, express, socket.io and mongodb. I am pretty much self-taught but when it comes to authentification, I can't find a tutorial that explains how it works in simple terms.
I have a login form, a signup form, the user data is stored into the database on registering. When I login, the page greets me with my username, but when I refresh or close the tab and come back, I have to login again.
All I want is that make users able to come back without having to log in systematically.
All I can find are explanations like : http://mherman.org/blog/2015/01/31/local-authentication-with-passport-and-express-4
And I don't really get it.
Can someone explain what am I missing here ?
Session management is something that Jekrb highlighted and is also a great question when it comes to highlighting users if it be anonymous or users of your application.
Though before I go into any depth I am going to highlight that cookies have a slight problem if your application is going to work on a larger scale where you have this scenario: "What happens if you have N servers where N > 1 ?" so to some degree if your unsure of your user-base, cookies may not be the correct approach.
I'm going to presume that you don't have this issue so providing cookies as a means of identifying users is appropriate, but isn't the only method available.
This article outlines a few ways in which the industry tackles this:
https://www.kompyte.com/5-ways-to-identify-your-users-without-using-cookies/
My favorite method here would be canvas fingerprinting using https://github.com/Valve/fingerprintjs2 Which will create a hash that you can store and use to verify new connections, Probably with something like socket.io which you've listed as using. A major upside of this is scalability as we can store these unique hashes centrally inside of the database without the fear of always being stuck with one server.
Finally I haven't posed any code which I dislike but the topic is hard to pin down to specifics, though I have hopefully offered some alternatives to just cookies.
Building a Facebook messenger bot using Claudia JS and plan on hosting on AWS Lambda.
I want to ask the user a series of questions.
When a user responds with an answer, I need to save that for later and once I have all the information I need, I will pass the answers to a function.
What is the best way to save this information?
I was thinking some caching layer such as redis but because that is stored in RAM I will lose it when lamda server shuts down. Mongodb apparently has a lot of overheads when connecting but will at least be persistent.
Perhaps just a simple mySQL server?
How does everybody else do it? I feel like there is a simple solution that I am missing.
I will first answer the part about how I'm doing it: I'm using a MongoDB. I toyed with the ideas you mentioned, but quickly crossed out in-memory solutions (Memcached, Redis) with the same reason. My final solution came down to either a relational DB or a noSQL like MongoDB. To be honest, at my project's scale, I did not think about robustly comparing performance between DB types.
With my particular feature "roadmap," I decided to go with Mongo to approach a more "OOP" style when dealing with the user "object" without having to explicitly define a user class, thanks to the normalized structure of Mongo. I understand the same could be done for MySQL, too, just that processing json data is more "object-like" for me and flask, i.e. user = getUserFromMongo, which gives me a dict in Python then I can just do user['first_name']. The codes belows will explain this simplicity:
(Somehow this was feeling like... not having to write SQL commands for simple database interaction in Rails)
My user object data on MongoDB
Finally, as to how I manage user input, I adopted Wit.ai's concept of context. I don't know how they do it exactly, but a context to me is the type of conversation purpose that is going on. I use it like a stack, and as soon as the current context is done, pop it off the context data of the user. For every message the bot receives, the program will get the current context and direct the flow. Whenever an unknown error occurs (exceptions handling), most likely because the user is saying something the bot doesn't understand, I clear the context data, too.
The good part about MongoDB is that I can shape the context however I want and treat it just as an object. A simple one is like {name: yelp-search, stage:ask-for-user-location}, and I imagine complex ones could be built on that structure, too. Of course, a stack implementation of the context does not deal with complex conversation with complex past reference.
I put my project on Github if you want to take a look at it.
i have also used mysql for chatbot but i have used NodeJS for the backend app.For that mysql module would be very helpful.
You need to store users' current state for the question answer session and also store the answer itself from the user and you need to make a switch or if-else-if case for asking questions to user based on its state as switch(state) and in cases of switch just update it's state.and you have user's facebook-id in event object of chatbot so that you can store data of each user individually with their state and question-answer in different table.
For e.g. define flags{1,2,3}
user's state will be 1 in begining so ask him for e.g. question-1
only,and store this as answer-1, you can do this by it's state
checking, and after this update status to 2.
so,in this way you can ask each individual student question as per
their state and answer him.
I've done the same in exact above manner.
Hope this would be helpful to you.
I am building a webservice with node.js and I am registering users in my service. I am using node.js + mongodb for my db and once I create a new user I also want to create a unique id for them and send that back as a response, just like all the great services like fb that send u back the facebook id. I do not want to send back the _id from mongodb, so how do I generate a unique id for every user in node, also is it better to do it this way or just send back the mongo _id.
is it better to do it this way or just send back the mongo _id
If you have to ask, it is better to just send back the mongo _id. Unless you have iron-clad reasoning behind why that simple, straightforward, make-life-easy-for-everyone technique is problematic, by all means, just send back the mongo _id.
If you decide the mongo _id is not good enough for you (probably due to FUD as opposed to any realistic reasoning), you have the following extra challenges you are adopting without any benefit:
you have to think more carefully about your indexes
Helper libraries functions like findById don't work for you anymore
Now you have 2 huge, hard-to-eyeball IDs to deal with on every record
helper libraries like mongoose are also going to be challenging to leverage
You will have to be mapping back and forth between _id and mySuperAwesomeExtraneousId constantly during debugging for the entire lifetime of your app
K.I.S.S.
That said, you can always just use an additional mongo ObjectId as they are perfectly valid unique Ids:
const mongo = require('mongodb')
let mySuperAwesomeExtraneousId = new mongo.ObjectID()
Use coupon-code.This is simple to use and solves most of the use cases for generation of unique ids.
https://github.com/appsattic/node-coupon-code
https://github.com/broofa/node-uuid
There are numerous good reasons for not sending back the _id created by Mongoose by default for example. For one, those IDs could easily be guessed by a rogue entity or hacker. And it's also never a good idea to expose your database ids anyway.
For an app that relies solely on a unique ID for a password-less account access, generating a highly unique hash id may be the best option. The perfect node module for that is hashids
You may also give crypto a try:
require('crypto').randomBytes(48, function(ex, buf) {
var token = buf.toString('hex');
});
good luck!
Use http://mongoosejs.com as an abstraction layer to MongoDB. It will ensure that you always have the _id available. It also will manage many other things, such as validation, connections, etc.
Pros: It is simpler to use than raw drivers, while at the same time maintaining all the power of a raw MongoDB driver. You will be up and running in about 20 minutes after visiting the mongoose website. Its one of the few times you don't trade off power for simplicity. It is a thin abstraction layer, you will have a net performance gain in code by having this single, robust layer in place then by trying to re-invent the wheel on every single part of your code that needs to access the DB. It supports every single MongoDB feature. It provides validation. It provides a simple interface to managing indexes. It automatically creates databases and collections. Built by the same guys that made ExpressJS, Socket.IO and Mocha for node.js. The list goes on.
Cons: Does not support multiple MongoDB connections. This is usually not a problem though because you will most likely use MongoDB's sharding features before you need to create multiple connections to multiple MongoDB clusters. It has a silly name.
We have been using Mongoose in production environments for quite sometime. If you want to see it in action, look at ZingProject.com. Its entirely node.js + mongoose over MongoDB. Its lightning fast.
I am currently using J Oliver's EventStore which as I understand uses Guids for the Stream ID and this is what is used to build my aggregate root.
From a CQRS point of view and a DDD perspective, I should be thinking about the domain and not GUIDs.
So, if I do a GET (Mvc client), am I right to say that my URL should have the identity of my domain object (aggregate root) and from that I get the GUID from the read store which is then used to build my aggregate root from the event store?
Or should I pass the GUID around to my forms and pass them back as hidden form variables? At least this way I know the aggregate root id and do not have to query the read store?
I suppose the first way is the correct way (not using GUIDs in forms) as then all my Gets and POSTS deal with identities of domain objects rather than GUIDSs which the client will not know.
I suppose this also allows me to build as REST based API which focuses on resources and their identities rather than system generated GUIDS. Please correct me if I am wrong
In my opinion you are on the right track here. The ui should rely solely on the read model and not really care about the aggregates. Then when you need to send a command you can use the read model to get the id of the aggregate you are interested in. The read model should be very fast to read from anyway (that's the whole reason behind using different models for reads and writes) and very easy to cache if you need to. This will also give you much nicer urls.