I really like the way Angular-Fullstack scaffolds the project. But I already have data served through a restful API. So I don't need any server components. Is there a way, I can only use the client part and remove the server components ?
Update: I am aware of generator-Angular scaffolding but I would like the way Fullstack scaffolds.
Thanks.
Using angular generator would be a better choice. It only deals with the front-end (such as your case).
Update
The guys behind angular-fullstack already started part of the de-coupling. check ng-component generator.
Related
I am planning out my first project using a Headless CMS. I have settled on using Strapi for my project. Is it logical to use Strapi while not using SPA framework/library? I want to use express and EJS to build my website and Strapi as the backend. Is this okay to do? I assume you would use this with your node server that will make REST requests to the Strapi API. Am I glossing over anything?
It's definitely logical. Just make sure to create your own API-endpoints within Strapi and secure the data as much as possible. So try to do most logic within Node.js and not within front-end.
As far as I am concerned this is pointless to make a headless CMS like strapi, without using a library/framework. There is so many reason why this is no sense. Above of all, in react you can use reusable components, writing in jsx etc. This is something that vanilla javascript no have.
Learn how to make first blog in react and connect it to strapi would you take about 10h if you know basic of javascript, css and html. This my opinion.
I'm in the process of updating an old piece of software (running Apache2, PHP, MariaDB, HTML, CSS) to use a React frontend. I'm completely new to React and I'm between beginner and intermediate with vanilla JavaScript so I've been researching this the last few days.
My confusion is about backend with a React web app. If I want to keep the existing architecture in place aside from frontend, will I be able to painlessly have my apache2/php integrate with my React app? And I'm also confused about the role of Node.js. Some places describe it as just extra libraries, and some places describe it as an Apache2 replacement. I think the source of my confusion is that so far in learning React and Node it always requires me to run npm start. Which feels very much like running a server like apache.
I guess in a nutshell my question is - what will my project structure look like when using a React frontend? Will I have just javascript files and host that on Apache? Or will this need to be run on Node? And where does my PHP fit in, will this need re-written in JS?
EDIT : For further clarification. I'm asking about the differences between a Node.js server and Apache2 server. That's the focus of my issue. Additional points of discussion to help me understand the problem are how PHP and React fit into all this, and whether my understanding of Node as an Apache-like tool is correct. Hopefully that makes this question less broad
For the purposes of building a React app against an existing set of web services: Node.js is used only at build time. It is used to execute the build tools which generate static files which are deployed on your Apache HTTP server.
Node.js is also used to run the development server for the React application that hot reloads it as you save changes to the source code.
Node.js can be used to run an HTTP server which hosts web services written in JavaScript (which which case it either replaces Apache or sits behind Apache (which is configured to act as a reverse proxy) … but that isn't your use case.
Stumbled accross NextJS in npm and tried it out. Look pretty good and relatively easy to use. However, one thing about it is still not clear to me:
Suppose I want to have also have a NodeJS (or whatever) api server in complement with the server side rendering that NextJS offers. Do I need 2 server then? For example:
Also is NextJS just a rendering server (which can render React components and creates HTML) or something else/more?
You can definitely use the same server to implement your api.
On official documentation page about Custom server and routing there are examples of integrating with popular node frameworks like express or koa - so you can use them for regular purposes.
What about nextjs itself - like it's said on official documentation page:
Next.js is a minimalistic framework for server-rendered React
applications.
So it has not only capabilities of server side rendering, but also routing (including client one), css-in-js setup and so on.
I stumbled upon google's material design web components ("https://material.io/") and would like to implement it in my projects. The only problem is that I've never used a javascript frontend before.
Note: Google's Material Design is the successor of Material Design Lite.
I received a recommendation to learn angular and implement Google's material design components through angular and have my frontend (angular) communicate with my backend (django) through an API.
1- Is this really the best way to proceed if only the web components are needed? Can we not just import the CSS and JS like we did with bootstrap and use Django/jinja to render views?
2- It seems like node.js / NPM is required to use angular and Google's material design, however, is that just during development? Or will we face complications when trying to deploy a django backend and javascript front end?
You can certainly separate your frontend and backend, but I don't think that's necessary in this case. You can definitely import your needed JS and CSS without separating the two, (just make sure that you have them in your base template so that they're accessible to all pages). All you need is a CDN. If you want to use raw SCSS as mentioned in the webpage you linked, you can always use Django scss https://github.com/jrief/django-sass-processor
Onto your second question. Node.js is essentially a platform so that Javascript can run on a server as a backend , as opposed to in a browser. Angular is a frontend framework (just like Django is for python). You don't need node.js to use angular.
NPM (node package manager) is a javascript package manager for node.js, just like pip is a package manager for python. It's not necessary if you're not using node.js.
I don't see anything that would suggest that splitting frontend and backend is necessary for using material design, so you should definitely be either to do so either way. Entirely up to you.
After past experience with Laravel and Backbone, I've recently gotten into contact with Ember.js and Meteor (for different projects). I really like Ember.js for its structured, route-based approach and for its open and forward-thinking community. On the other hand, I really like Meteor for its simplicity; how fast you can get something working.
There is one thing that I really love about Meteor, which is the DDP Protocol. The reason I ended up using Meteor for a project was because I wanted the best Websocket solution, and DDP's simple combination of RPC for client->server and PubSub for server->client is absolutely brilliant.
Would it be possible to connect Ember.js with a Meteor backend, and how would I go about doing this?
There's some work done for AngularJs: https://medium.com/#zfxuan/the-wonderful-duo-using-meteor-and-angularjs-together-4d603a4651bf
The best option that you have currently for Emberjs is to create your own solution.
I've a background in AngularJs but I don't like the idea of using AngularJs + Meteor. The same goes for Emberjs or any other frameworks that are redundant. By adding AngularJS/Ember/others you're increasing your project complexity. Meteor is great because every plays nice together but there is still a lot of work to be done by the MDG or by community packages.
You can simply use DDP in your application but then you're going to reinvent the wheel. Meteor already handles DDP, in-browser database (minimongo), the UI is reactive (Blaze), the auth system is integrated at the client and server, etc, etc, etc.
You can use 3rd party plugins with your Meteor app but trying to replace parts that Meteor already provides is the quickest way to have a really hard project to maintain. But, in the end, it's just my opinion on this topic and you should use whatever makes you happy.
Maybe you should consider sails.js: http://sailsjs.org/ it has support for SQL systems and probably serves best your purpose.
You can indeed connect other apps to a meteor backend without using meteor on the client.
Meteor has a full wiki page on different libraries. I think that is the most up to date source for information on libraries to connect to a DDP meteor backend.
A link to the JavaScript section: http://meteorpedia.com/read/DDP_Clients#JavaScript