Context
Our project has a Java back-end that accesses a Neo4j database. The back-end is nearly finished. Previously we intended to build a Java desktop client with a JavaFX UI. Now we are considering building a web application instead. I will be building the front-end. My previous experience was mostly using Java. I will have to learn a new language. The thing I'm having some trouble with is determining which one is best suited for this project. Before we begin front-end development we also want to ensure that the web app will be able to handle all features we had planned for the desktop client.
Requirements
Connection
Send HTTPS requests (not expecting any problems here)
Keep a persistent HTTPS connection open to receive server-sent events
Data
Store and handle considerable amounts of information received through server-sent events (potentially millions of events)
UI
Create a beautiful and highly reactive UI
Create complex custom components
Drag and drop support (also not expecting any problems here)
Integrate a view of an external site into the UI
Platform
Platform independence
No need for browser plugins
Candidates
These are some candidates I have identified during my research:
JavaScript with React
ASP.NET
Python with Flask
React js for the front end. Most anything for the backend. We use Python/Flask for routing and inserting into templates. But, you will really appreciate React for its "reactive" UI. It's incredible what it can do. I see no problems with the task list you've given.
Related
I am planning to build a react native application, where at some point i should use a database, which database is suitable for online react native and how will i connect db with my react native code?
Databases should be linked to the server, and not directly to the app for obvious security purposes. An App is just like the front-end part of a website: if it's executed in client-side, it's not safe.
So any back-end framework with a SQL DataBase will do (PHP frameworks like Symfony or Laravel or NodeJS) You will have to get your data with react native's Linking fetch API, by adding a token if you want to limit the access to connected users only.
But good news, if you're not very comfortable setting up a server, you could always choose a server-less solution like Firebase .
I definitely recommend it. You could save a lot of time and end up with a very secure and fast solution to manage your app's data. Just be aware that only a limited number of requests per day are free (but don't worry, it's not that expensive and it gets paying only with a great number of request per day). You will have to learn how to use it by reading the docs though, it might take you a couple of days, but trust me it's not rocket science.
(Disclaimer: I'm not advertising for Firebase, I just enjoyed using it so I recommend it)
When I search this in Google, I'm getting more results regarding progressive web apps with angular, than react. Why is this the case?
I'm in the beginning stages of learning ReactJS, but I eventually want to understand PWA as well. Are these two completely different? Is it possible to build an entire scalable application using these two? I'm learning that the popular stack is Node + React + MongoDB. Does adding PWA benefit this or is there no point?
Is progressive web app still a thing? Is it here to stay for a long time or is it already a thing in the past? Just looking at the tags in stackoverflow, its not being talked much.
The concept of progressive web app is not limited to any javascript front end framework.
A Progressive Web App (PWA) is a web app that uses modern web
capabilities to deliver an app-like experience to users. These apps
meet certain requirements, are deployed to servers,
accessible through URLs, and indexed by search engines.
So it can be web application made using simple vanilla javascript / angular / react / vue or any other.
To consider your application be PWA it should meet following requirements :
Progressive - Work for every user, regardless of browser choice,
because they are built with progressive enhancement as a core tenet.
Responsive - Fit any form factor, desktop, mobile, tablet, or whatever
is next.
Connectivity independent - Enhanced with service workers to work
offline or on low quality networks.
App-like - Use the app-shell model to provide app-style navigation and
interactions.
Fresh - Always up-to-date thanks to the service worker update process.
Safe - Served via HTTPS to prevent snooping and ensure content has not
been tampered with.
Discoverable - Are identifiable as “applications” thanks to W3C
manifests and service worker registration scope allowing search
engines to find them.
Re-engageable - Make re-engagement easy through features like push
notifications.
Installable - Allow users to “keep” apps they find most useful on
their home screen without the hassle of an app store.
Linkable - Easily share via URL and not require complex installation.
For more information visit the Google developer guideline for PWA
So, I've been fiddle:ing with some isomorphic React + Flux lately and have found some concepts quite confusing to be honest. I've been looking into best practices about how to structure isomorphic apps and are looking for advice.
Suppose you are creating a webapp as well as a mobile app backed by the same REST API. Do you bundle your REST API together with the webapp? I've seen people advocating both bundling and having a separate codebase for the REST API.
Any advice or suggested reading is appreciated!
Fluxible (atleast from the examples) does advocate using the service layer inside the application calling it directly from the server and via xhr from the client without duplicating the code
https://github.com/gpbl/isomorphic500/blob/master/src/app.js
This is an example I followed religiously while building the isomorphic app
The idea is very simple. Let's assume you have SPA and a backend wich provides REST API.
SPA (in browser) <====> Backend REST API
in isomorphic case, it is absolutely the same, except you will run your SPA on the server too.
So, it will work like that:
SPA (in browser) <====> Backend REST API
SPA (on server) <====> Backend REST API
If you have a mobile app then it will be:
SPA (in browser) <====> Backend REST API
SPA (on server) <====> Backend REST API
Mobile app <====> Backend REST API
Here is a real isomorphic production application opened by us to the community - https://github.com/WebbyLab/itsquiz-wall . You can just clone it and run.
Here is my post which describes all the ideas behind the app in details.
Let's see if I can help you.
Please keep in mind that Isomorphic Javascript is quite new and it is hard to find clear definitions for every use case.
By definition, if you create a RESTful application you should have a clear separation between server and client:
"A uniform interface separates clients from servers. This separation
of concerns means that, for example, clients are not concerned with
data storage, which remains internal to each server, so that the
portability of client code is improved. Servers are not concerned with
the user interface or user state, so that servers can be simpler and
more scalable. Servers and clients may also be replaced and developed
independently, as long as the interface between them is not altered."
Regarding isomorphic applications, the main benefits are:
Not having a blank page when the user first enter the site (points for UX)
Therefore it is SEO friendly
And you can share one logic between server/client (for example regarding React Components)
This means you should deliver rendered React Components from the server to the client when the user first enters a URL. After that you will keep using your REST API as usual, rendering everything on the client.
If you can, share more details about your case and it will be easier help.
I wouldn't recommend you to bundle the REST API in the browser, as you are limited to using browser-compatible modules in your API, and you won't be able to make any direct database calls.
There's a library that makes it so you can build your APIs in an isomorphic fashion, and re-use it in the client and server without bloating or breaking the bundle. This is what we're currently using in a big single-page application.
It's called Isomorphine, and you can find it here: https://github.com/d-oliveros/isomorphine.
Disclaimer: I'm the author of this library.
Context: I'm a beginner programmer, self taught in the hope of making a SPA. I've started with JavaScript, Jquery, PHP and MySQL, and now feel pretty confident with all. I've started with Ember, and am now moving away from having a PHP API to Node. Which has then brought me closer to Meteor... I'm aware I'll need to use Mongo instead, but having an integrated front and back seems to be sensible and have some advantages.
So my question is what are the advantages of having a separate REST backend API (eg Express) rather than an integrated front/back (eg Meteor).
One that springs to mind is that my app will be tablet/pc based, but in future I'll want a different mobile version, so I'd be able to use just use the same API. I'm conscious that the above question is the main concern with this stack question, but perhaps if a meteor developer could clarify whether this is indeed a concern.
Thanks in advance!
well for me you'll get a lot of advantages using a rest API, they are lightweight, extensible and overall reusable.
today it's a trend to use a vertical architecture that means having a RestFul service with a single responsibility, why because it scale better and it's easier to assign a team to an api, so that way you'll be able to manage several teams and apis in a very ordered way. This is probably how Twitter, wunderlist and other companies works, because it's a solution to scale better.
take a look to this talk by Raffi Krikorian he was the head of architecture of Twitter for a while is a little bit old but it worth every minute and to illustrate some of the advantages.
Also you can look at the diagram below, I did while ago it explains the differences between the MVC and API first type of architecture.
I've authored one rest app using angular and rest services and it has been a very nice experience to me there's no way back.
good luck
Meteor doesn't really "integrate" the front (client) and backend (server) as you describe. It still maintains them as two separate layers. The beauty of meteor (aside from the insanely awesome reactivity) is that it uses Javascript everywhere, instead of using JS on the client and some other language on the server, so you can use the same APIs on both the front and backend. Although Meteor does snazzy things like let you write client and server code in the same file, it still requires you to distinguish between the two, and server code is still stored only on the server and client-side code is still served down to the client.
Meteor is still young, but the developers and community are very active, and everything you described can be achieved with it at this point. I've been working with Meteor for about 6 months now, and it hasn't let me down yet. I'm working on a production-level application that also requires exposing a REST API for consumption in mobile apps, which I'm doing quite successfully with Meteor (I just updated a user profile using a REST endpoint from an Android device and watched it change in the Meteor app in realtime. So cool!).
I was using this great package, RestStop2, for building REST APIs in meteor, but it was unfortunately deprecated, so I released an updated version. Check it out for an example of building REST APIs in Meteor. It's available through the Meteor package manager: https://atmospherejs.com/nimble/restivus
So to answer your question, you always want to separate the REST API into it's own layer, but that is entirely possible with Meteor. To make it clear, you would never consume this REST API from within your Meteor app. Meteor uses DDP (not HTTP), which gives you a much more direct connection with your server, so you're doing something wrong if you're accessing data on your Meteor server from a Meteor client via HTTP. Of course, with Meteor, you have the advantage of being able to use existing code from your REST API.
There's a really good write-up that explains some of the considerations of writing a REST API in Meteor: http://www.meteorpedia.com/read/REST_API.
The design of a architecture separated in layers like frontend, backend (Rest Api) and DB, is for obtain a better a scalability, reusability and logic separator of features of the application. For example:
Today make a web applications separated in 3 layer (frontend, backend,
and databases), if tomorrow you wanna do a mobile application you can
develop the application like a extra project in the frontend layer,
but use all the features developed in backend. Then the frontend
application not need servers why run inside every device, but maybe
the load in the backend servers increase, and you only need add 1 more
server in the backend layer.
Its a little example, but is the most common case in this new era of mobile applications.
Remember always this in MVC architectures:
Frontend: Always call services from the backend, render the view, and capture data. Sometimes make a litle logic.
Backend: Receive the request, apply all the business logic, read and write operations in databases, and return a response preferred in json format.
Model: store data, backups, slaves, etc.
PD: If you use meteor in this example you gonna need to make a api Rest to develop the mobile application.
I'm using HDIV for JSF and Spring MVC applications to mitigate OWASP top 10 security risks. Now I have to implement the same in AngularJS.
Is there any library avilable similar to HDIV for AngularJS?
For client-mvc scenarios such as AngularJS Spring-Hateoas approach fits well with HDIV. Actually, HDIV has a module for that integration: https://github.com/hdiv/hdiv/tree/hdiv-hateoas
It’s not totally finished yet but the integration of URL resources works (see ResourceRequestDataValueProcessor) but it’s not finished the support for forms. When we started this module this data format for forms was not finished or defined, and that’s why we did not continue this work.
We think it could be possible a very integrated solution with HDIV following Hypermedia and HATEOAS
approach for client-mvc apps or also for native mobile apps. In other words, within REST Hypermedia approach all URLs or forms, excepting the first URL, are created in the server side, in a similar way of traditional server side MVC web technologies.
Please take a look to this module (hdiv-hateoas) and we can support you if you have any doubts.
Roberto Velasco (HDIV team)