I have been considering the best process to store user data online.
An example of the usage I need:
Think of it as a collaborative story-writing app. One user writes, say, a paragraph of the story. They "submit" this paragraph and all the other uses of the app who have subscribed to this user will be near-immediately notified and will be able to check their app for the update. The subscribed users can then write their own paragraph, and submit it, which alerts the original poster and all other users.
I mostly just need the database functionality. It would be fantastic if I could make use of Facebook's friends functionality, but I guess I could use both of the below approaches...
The approaches I have considered:
Using Unity's Facebook.API
When I was originally conceiving my concept a friend suggested using the Unity FB.API as a way to store the information online. However from what I understand FB can't really be used as database, which is what question one involves.
Hosting my own Server
I am familiar with Node.js, and have used it to create and manage small servers, just for University assignments. So I understand the basics of whats involved, and the way I see it I have two options here: paying for a server or hosting one on my home PC (just for early development).
If I do it this way, I could save the data in JSON for example and read it to the user as required.
{
"story": {
"name": "Nice Story",
"paragraph1": {
"userID": 2366,
"text": "One day I wrote a nice story"
},
"paragraph2": {
...
},
...
}
}
But probably with the paragraphs in an array! Similarly I could also store stories/users/paragraphs in Mongo etc.
So, to get to the Question
Simply put, there are three parts:
Can Unity's FB.API (or any Facebook thing) be used to store information like I require?
Would using a Node.js server be a more effective way to achieve my functionality?
Is there another way?
Thanks in advance for your time!
No, the Facebook API is not a custom database where you can store your own stuff.
A Node.js server would be "one" way to store data. For example, in a .json file, or in a MongoDB database, or whatever. That´s pretty opinionated though. You can use any server/technology you want.
There are hundreds of other ways, a simple one would be Firebase.
If you can pay around 5-10 bucks a month for a hosting site, most have an integrated database that you can use to store data.
Related
I suppose this type of topics always exist, but i like to have an specifics opinion for my case.
Since 1/2 month i'm thinking about make a listing web application for my daily life (shopping, due, etc.)
I started out define my object model like this (very simple design model)
Models image
So, i decid to create a NodeJS API for back-end, and Angular 7 for front-end. It's not a technical problem for me to develop the application and the API, but my problem is in the design of this, and particuly to the routes design.
My first suggestion for routes API is :
User :
/users
/users/:id
List :
/lists
/lists/:id
Element :
/elements
/elements/:id
Technicaly it's ok, but i'm not sure it's the good practices.
As User contains List and List contains Element, Wouldn't it be better to have routes like this :
/users/:id
/users/:id/list
/users/:id/list/:id
/users/:id/list/:id/element
/users/:id/list/:id/element/:id
Thanks for your answers, or suggestions !
PS : If you have any web sites / video / topics ... to suggests, do not hesitate.
I'd say you got it OK in the first place, the second approach is messy as you can get huge routes, and you're sending a lot unnecesary data. Why do you need the user id to get an element? An element is an entity by itself, and it will probably grow, you may need to get related elements, filter them... its better to just have /elements
What you can do is find simple relations, like:
/users/:id/lists
/lists/:id/elements
I'd recommend reading building apis you won't hate :)
Firstly you are in absolute correct path of defining Routes in angular, at the same time you have to use Lazy loading concept of Routing.
I would recommend you to, go for plural sight course , by Deborah Kurata. I'm not trying to promote or advertise anything but for your current situation that course would be the right guidance. It would provide you all the necessary things that you need to build enterprise ready apps.
Alternatively Core UI Angular provides some best designs which are already implemented with Angular Route and things. Lazy loading and other Angular routing are implemented, all you need to do is understand it.
Hope this helps.,
Principle
as short as possible
easy to read
user-friendly input when the user enters the URL
Examples
User list
/users
User detail
/user/:id
Add user
/user/new
User's functional page
/user/:id/tel
I have 1 project which is divided into multiple SPA, I have 5 SPA, written in 2 in Angular, 2 in react and 1 in vue js. Now I have an integrated server which will serve the different files as per routing. I need to share the data from one app to another with least interaction of database. This is a scenario of micro frontends. Hope this clears my problem.
Any help will be appreciated.
There are three ways with which you can share data:
URL: Query Params/Path Params (Only for small data like ID, filters, etc.)
Session Storage: Use this only if you are not navigating to other tab/window
Local Storage: Most convenient and preferred way
Of course, if you are persisting state to Local Storage, then you have to handle flushing of the state by yourself when the user logs out.
This is a bit painful process to handle. You will have to write code to manage serialization and deserialization of JSON to Local Storage. To ease this, it is better if you have the same state management solution across all micro-apps. I recommend the use of Redux/MobX to do this. But if you are using Redux for React, Ng-Rx for Angular and Vuex for Vue, then you will not have any ready-made solution.
Also, when you are saving the state to Local Storage, either debounce it or do it lazily with little delay for performance reasons.
We are using micro-frontends for last two years and we use the mix of Local and Session storage to do our things. Luckily, for all the apps we use Redux, even with Vue, and that allows us to use redux-localstorage.
You can also use Cookies but it is generally better to avoid them.
1st, Custom element creation
I have worked for micro-front-end elements base architecture with #Angular/element module. As I worked, I used bellow flow
For code, I have followed build-a-micro-frontend-application-using-angular-elements.
Here it will provide you elements like native html elements.
2nd, Another good approach is to use library feature in angular. You can write your components, directive or pipe, then publish them or use them into other project directly. In this approach again you can reuse the same code.
3rd, We can use i-frame, but now days it is causing lot of security issues from browser.
Another option is to use a frontend event bus like EEV. Your application shell would be responsible for creating a shared event listener. Then each micro-frontend could emit events on that shared channel.
You could also use an RxJS Subject as a message bus within your App Shell and subscribe to it in the Micro Frontend Applications. Here's an example
I hope that gives you a couple additional ideas.
I came across same scenario where i have to pass the data from one micro-app to another.
and after lot of R&D i found that event based communication is the best , where i transfer the data in form on Event Objects.
here is some Example:
For sending data:
var event = new CustomEvent('userData', { "detail": { "id": id, ...rec } });
window.dispatchEvent(event);
and for receiving the data on other app is:
window.addEventListener("userData", function (e: CustomEvent) {
this.id = e.detail.id;
this.country = e.detail.country;
this.contact = e.detail.contact;
this.company = e.detail.company;
this.changeDetectorRef.detectChanges();
}.bind(this));
This approach does not need the DB communication.
Hope this will resolve your query!!!
Happy Coding!!!
My issue is that I don't know what is considered a good practice for storing the chatbot's answers. I do not wish to have the answer in plain text inside the bot.dialog() in code like this:
bot.dialog('Greeting', session => {
session.endDialog('Hello, I'm a bot.');
});
... But instead fetch the answers from a database or a local file.
Since the bot is supposed to run in Azure, I've been looking at Azure Cosmos DB with MongoDB, but are there better alternatives? Given the simplicity of the database, would be a better practice to store the bot's answer in a local JSON file and store it in the same catalog as my app.js file?
The bot is supposed to be an FAQ bot, so the DB/file would mostly consist of answers that the bot is going to give for the different types of dialogs. There will most likely be no relation between the data.
I'm working on an app that i being built using Node and Express. All is fine, however the app is currently not asynchronous and I'd like it to be, so I'm currently investigating what would be the best way to do it.
As far as I can tell, socket.io seems to be the preferred choice to go with Node.
My question is, is socket.io's methodology the best way to move data between the server and client or is there a better, more robust way to do it? Maybe something accomplished with Node only?
PS: I think socket.io sounds really nice. Its just that I'm new to Node and though there would be a simpler way to move data back and forth.
Many thanks
EDIT:
Ok, I've seen the term "realtime" used before and was frown upon. The commenter implied that technically there is no "realtime" application, hence me choosing asynchronous, however realtime does describe what I'm after: An app that will be all ajax-like. For instance, in my app, when I need to edit a saved document (mongodb records are called documents), I need to redirect the page passing the document id as argument. I don't want that. I want all through ajax. I can achieve this with jQuery, however behind the scenes the server will still be moving through urls (I'll need to create loads of app.get('product/:id/edit', ...), app.post('/product/:id/edit'. ... and then use $.ajax to get and post stuff ) so I was wondering what's the best way to achieve this.
PS: I might be looking at this completely wrong. Like I said, I'm new to Node and for app development for that matter.
EDIT2: An example: Let's say I have a page with a table in it where I list all products. Each product will have a EDIT/DELETE button. At the moment, when I click edit, I'm redirected to another page where I can edit the product and save it, then I'm redirected to the product listing. I'd prefer to load the product into a modal window, make whatever edits I need, then update the product/listing without leaving the page.
Using $.ajax I can use the product ID, enquiry the db for that particular product, populate the field in the modal with the product details and display to the user. Then allow the user to make the changes and update the products, however the part in which I need to enquiry the db in order to populate the modal is muddy because the id needs to be passed through the url...
I don't know how to pass the id to the application unless is through app.get('/product/:id/edit', ...) then app.post('/product/:id/edit').
I want to use the spotify api to create a webapp. Without going into too much detail about the project, I want to clear up whether it would be against the terms and conditions or not.
After reading the terms and conditions, i read this line under things NOT to do: "aggregate Metadata to create data bases, or any other compilations of Metadata".
I don't plan to do any automated requests, for example, hammering the service with different queries to build a database... I'm just wondering whether I can store results from users who have performed searches via my application to the api, so that I can build content from my database on other parts of the application.
Thanks
I'm not a lawyer, so you'll need to have a lawyer confirm this (contracts, including ToS contracts, are important), but the general gist is that if you cache the results of user-generated requests to create features then you're ok. If you start caching stuff not generated by a user, you're in muddy water.
Good:
Other users who searched for "Madonna" in MyAwesomeApp also searched for "Backstreet Boys"!
Bad:
Here's a list of all the blue cover arts on Spotify: [list]
To generate the first example you can cache and work with searches explicitly done by users of your application. The second would require scraping all of the coverart in the service, which isn't allowed.