So, I have been learning Vue.js as my first js framework for some time and after I made some simple SPA:s without much interactions with a server I started to wonder: What should a backend be like with Vue? For education purposes I gave it a try and came up with some pattern on my own and now I can't imagine anything else, maybe I got some wrong idea.
What I came up with: I made a simple API with PHP which was receiving requests from the frontend (Vue component methods reacting on UI events) and requesting data from the model or updating data through it.
There are a lot of different Backend Solutions and you should take what fits your websites purpose and also personal preference the best.
If Backend includes Hosting in your case then you basicly have the 2 big options:
a) A Server where you run it ex. via an Reverse Proxy (example: Digital Ocean)
b) A cloud computing Platform (example: AWS, Heroku, App Engine)
But you only need to host it that way if you actually run the app and retrieve dynamic updates on the page, new routes get added when you for example publish a new Post.
If that is not the case then a static hosting provider would be enough, there are 1000´s of them and they are pretty uncomplicated.
If you mean which Database to use, then it also comes down to preference, do you want a SQL Databse or a NoSQL Database like MongoDB? As a personal recommendation I would suggest you to use Firebase as your backend for your experimental app, the free plan is far than enough for testing purposes, you also have a smooth and easy to integrate Authentication System avaliable and you can also take quick advantage of things like Push Messages, Cloud Storage Buckets and more.
Note that Im not related to FB by any means and this is just a personal recommendation, but I feel like your Question is pretty opinion based so maybe be more specific about your goals or just comment down below if you got any more questions.
Related
This could be a silly question but I want to confirm about it. I am a backend Laravel developer and have created my website. Now I want to create mobile mobile apps but have no knowledge of front-end.
Due to lockdown situations I want to use this time to create the backend API for my apps. Now I want to know is it ok or a normal practice to create APIs without knowing anything about front end. (Like is it possible that I just create all the endpoints now that are throwing data in JSON and then the front-end developer will use them to integrate in the front-end? Thanks
P.S: I dont know how the app front-end will look like but I know what data will be needed in each page/view.
I think you can do this easily with graphql.
A Frontend dev and also beginners with Apollo in the frontend can easily introspect and build the stuff.
If you can choose your Frontend stack there is no problem with rest either.
I always do the Frontend first approach.
Mocking the data for graphql types and building the api later seems to me the best workflow ever.
See ya. Much fun with your project
Yes it is possible very possible to do that it would be nice is the API is well documented using postman or swagger for a better experience when frontend engineers want to integrate
Many API's in the world today are never consumed by a browser or app on the frontend, sure it can make life easier knowing why you are building it.
But at the end of the day, a good API is simple and easy to understand. It just allows a developer to fetch data from a system but normally with some idea about each type of request.
For example, if you had an API for a university the endpoints could be as follows:
/pupils => Get/Sets pupil data.
/teachers => Get/Sets teacher data.
/classes => Get/Sets class subjects and references ID's of both Pupils and Teachers.
So if you wanted all the Pupils in a given class you would query the /classes endpoint and then for each Pupil ID you would query the /pupil endpoint.
Sometimes not having a frontend makes the API even more generic because you might think differently when you do not have a frontend.
My boss asked me to find a way to completely disassociate our front-end application from the back-end in the local environment, currently I'm the sole developer for both our back-end software and the front-end, so using Docker I'm able to mimic a production environment and work on both projects separately, (we don't render on the server side), his idea is to mock literally everything, so in theory you wouldn't need the back-end software to develop the front-end.
Two of the (more reasonable) solutions I've thought of are:
Mocking all of the network requests on the frontend, these functions will
run instead of network requests.
the problem with this approach is that it is not persistent, all of the data is randomly generated for every request, and in a system that is so oriented around forms, tables, and lists, I feel that getting the data you're expecting after a form submission is a must.
and in order to persist data, every request would have to go through some sort of data store (Mobx, Redux, etc...) and even then, if the page refreshes, the data is gone.
Initiating an express server and DB on top of Docker along with Webpack, and mimicking the production server requests and responses using db seeders, this way the front-end is persistent.
Obviously, this approach would generate plenty of work, and in order to make sure the express server is correctly mimicking the original back-end software, it too will need unit tests and mock requests.
While mocking the data is great for unit tests, this doesn't seem like the way of doing front-end with such a small team to me, is there a good approach to achieving this that I cant come up with or find? or is this an exercise in poor decoupling strategies?
What you are looking for is a Mock API. There's plenty of packages for it where you define example requests in a JSON format. A lot of these also handle persisting data for a short amount of time.
From a strategy perspective using these can actually make a lot of sense to automize end-to-end-tests, which shouldn't rely a production API. Whether it's the right choice of developer time in a one man team depends on the long-term perspective of course ;-)
I'm still new to web development. To learn more about JavaScript(JS) and web development, I am thinking of writing a simple web app which pulls and records time-series data (say, the price of a stock) periodically and draws a live chart showing the historical data. In addition to price data, I would like the app to record/maintain some user-related info such as the ticker of the stock(s) associated to each user.
Ideally, I would like to keep the app light-weight and portable/standalone (meaning, reduce the dependency as much as possible, and the end user hopefully doesn't have to do a lot of configuration/install of dependencies). The issue that I cannot figure out is where to store the historical data. I looked around for database solutions which will allow the app to write data directly from the browser (that is, using JS) to the client's machine. LocalStorage and IndexDB are non-persistent as far as I understand. Some suggested using PouchDB, but upon looking at it closer, it seems like the user need to install CouchDB or some compatible DB (say, SQLite). But that means I cannot share my app with users who aren't technical enough to install and configure CouchDB or SQLite on their machine before using my app.
If anyone could share some insights as to which DB might allow a JS-based app to write persistent data to the client's machine (if such thing even exist), that would be greatly helpful. If there is no such DB solution, please feel free to let me know alternative solutions that would allow the goal of building a simple, portable, JS-based web app. Thank you!
I think the best solution is to use Electron.js. The whole idea of this framework is to create web apps that can reside on client machines. You could package up any DB option you want, or even better, just include an API to your backend through the web app and it will work on your client machine like I think you want it to.
As for DB options, there is a great thread on S.O. that talks about what is possible. It looks like knex.js is your best bet (full disclosure - I haven't used knex).
I'm working on a personal project with the MEAN stack and would greatly appreciate advice on which route I should take when setting up the server architecture. Performance and scalibility is important to me since I would like to build enterprise level web apps in the future.
This project will be a image hosting application which will include front-end, private API, and a file storage system.
Option 1: All on the same server
Option 2: Front-end and Private API on same server. File storage on separate server.
Option 3: Front-end, Private API and File storage would all be on their own server.
I'm thinking Option 2 might be the best option, but I would love to learn from those who have experience in building apps with a similar architecture.
Thanks!
Depending upon how much scale you are expecting and how much you want to spend on server infrastructure different cases are suitable. I will try to explain a best of both world.
For all the services which are API based, they should be on an infrastructure that can scale. For that reason, they are mostly in the form of servers which are always behind load balancers. Scaling takes places based upon traffic type and region. To do this, currently industry favorite is docker based microservices. Another comparable solution is Google App Engine.
For all the Front-End/UI based stuff, they should be stored on a CDN for optimized delivery. With CDNs you maintain that your application's UI will always be available to end users even if your private API based service is slow. CDNs are cheap and they will have a great impact on your end users.
For Image/Files storage, you should use a Blob storage based solution. Your server HDDs are mostly SSDs these days and they cost a bunch. Moreover those disks are attached to your servers hence really prone to errors or security issues. Using a blob storage is helpful since it takes care of redundant and scalable storage along with some form of security.
With this model, you will make sure that your files are safe and away from your business logic, your end users can access your webapp even when your core service is slow, and very easily manage server for API/service based scale.
You should not bake your server architecture right upfront. But measure along the way and improve upon the desired lacking features.
So I would go with the same server approach at first.
But design the Frontend as a serverless architecture.
Create a Private API and a separate File storage API for reading/writing. These can be microservices ready to scale when needed.
You can host the pieces on other clouds/or use your own to scale vertically/horizontally or geographically.
So you bake the scaling part into your design, but only scale when you need to.
Basically the only thing you need to take care now, that your architecture is decoupled into pieces so you are ready to scale when the need arises.
Note: two good read on the topics are the following: Infrastructure as Code, Building microservices
I've been developing a web app using Node.js, Express, MongoDB, Mongoose and Socket.io for some time now. Version one has just been released and is working great. For version two however, I want to completely redesign the UI and use a front-end framework such as AngularJS. I've been looking at the (MEAN stack) and it looks really promising. Before goin into too much details, I will try to explain the purpose and working of the app so hopefully you will understand my question later on.
My app is a streaming service and has 4 simple models: user, room, song, playlist. These are modeled through Schema's in Mongoose and are stored in the MongoDB database. When a user visits the app, it serves all the HTML through Node.js and Express (and Jade as templating engine). If the user then registers, Socket.io lets the server know a user register, that is then saved to the database and the user is joined in the lobby room. In this room, users can chat, listen to music, etc. This is what I've been using Socket.io for, the communication between users themselves and my server (the server sometimes serves html too through Socket.io). Basically all the messages between Socket.io and the server are really small (chat messages, room objects, song objects, etc).
I'm quite happy with this approach, however, on the client side, the code is not really separated. There are currently two JS files serving the logic. One handles the Socket.io events and manipulates the dom. The other one is a common JS file that does a bit of everything. These two files are now about 5000 lines each. This worries me and I want to find a solution for this in v2.
So I've been looking at AngularJS in the MEAN stack and how to incorporate it in my app. My question is, will this solve my client side problems and can would you recommend taking the effort to do so. Also, how well will Socket.io work with AngularJS? Having both of them might be an overkill for what I'm doing. Do you know of any possible other framework that might be easier to integrate with my current environment? I know it's a bit of a subjective question but if you have any tips or do or don'ts, thanks for sharing! I really appreciate your feedback and if you need more information, I'd be happy to share it with you!
Jordy
I think that real example will be sufficient: https://github.com/btford/angular-socket-io-seed