I'm confused about headless architecture and headless CRM. I have gone through various links for both headless architecture and headless CRM. Please have a look at my views on both:
Headless Architecture:
A system in which the backend is decoupled with frontend and backend APIs can be used in different apps.
Headless CRM:
A system in which we have APIs for managing the contents, but the front end can replace with any technology.
I have a few doubts about both:
Usually, the backend system is always independent of the frontend (i.e expose APIs to the frontend) which means all system is based on headless architecture?
If we talk about headless CRM, do we have a set of APIs for managing the content and is it not too complex to manage content using the APIs? Please let me know the basic overview of this term and some examples.
Related
I'm very stoked about Remix.run, but there's one thing I really don't get. In the technical explanation of the Framework it says:
While Remix runs on the server, it is not actually a server. It's just a handler that is given to an actual JavaScript server.
It's built on the Web Fetch API instead of Node.js. This enables Remix to run in any Node.js server like Vercel, Netlify, Architect, etc. as well as non-Node.js environments like Cloudflare Workers and Deno Deploy.
So.. is the backend a Node.js server or not? If not.. how can it execute JS in the backend? I think it a bit contradictory in the above explanation.
Remix is build with a lot of different adapters (not sure if that is the official term, but the idea of adapter is fitting). This allows remix to swap out parts of its architecture to make Remix "fit". Examples of those adapter packages are remix-vercel, remix-express, and so on. They all serve te purpose of converting the different interfaces of the requests/events on those platforms to the request/response model of Remix (thus fetch).
All the previous mentioned adapters are Node-based environments, but Remix also has some adapters for non-node environments. For example remix-clouflare-workers is an adapter designed to make the Cloudflare Workers environment play nice with Remix. Cloudflare Workers are not running on Node, in fact its not even a server but just javascript functions being triggered by events. Workers are running directly on the V8 Javascript Engine, the engine that is used by Chrome and Node to run JavaScript.
So yes, Remix can run in NodeJS environments as a server, but because of its adapter architecture, it can also provide adapters for non NodeJS environments, and be (serverless) functions, etc.
Fun fact, even remix-react is a seperate package (adapter), allowing the Remix team (or community) to implement adapters for other front end frameworks in the future!
I am doing a research on client/server architecture and web applications. I've been reading different thoughts and suggestions around the web. Some saying that web applications are not considered client/server architecture apps while others are saying the exact opposite. I was wondering what is actually the right thing and if someone can provide in depth explanation that would be highly appreciated?
It depends on the architecture/design of your web application(s). The rule of thumb would be: The client application has to be another piece of software than the (resource) server. There is no "one right way" to design a client/server architecture.
The most common implementations for web based applications are MVC (Model View Controller and SPAs (Single Page Applications).
MVC applications (like ASP.NET or ZendFramework) are applications that are booth rendering the client and handling the business logic in the backend and are not based on a client/server model. (An action in a controller handles a request, loads some data and renders an HTML view as the response).
But: If your MVC Application is acting as a proxy calling a "remote" web service internally (via SOAP or whatever), it should be considered a client application.
As an example: A CRM system is running in an intranet network and provides a data-services for desktop clients. You could write a web application that displays data from those services which is then another client application.
The SPA architecture requires the separation of the server from the frontend, the SPA being the frontend, which in turn is the client application. With this requirement you are basically already implementing a client/server architecture. Let's say an AngularJS frontend and the backend could be a REST service (like ASP.NET WebAPI or Lumen).
The choice of where you host the client application does not affect the client/server architecture, since the applications are still separated on execution: the browser executes the JavaScript SPA on the device of the visitor and calls the service in some data center.
Web application is a part of client-server architecture. Any implementations have always two or more tiers, so two or more process communicate each other.
You may take a look on my old presentation "Architecture of enterprise (automated) information system - Layers and levels" that shows different client-server architectures including web application case (the slide "Tiers are physical layers (examples)" shows examples).
Is there a way to compile a node.js application for multiple devices? I would like to use Electron for desktop (Chromium), NativeScript for mobile devices and also have a SPA for common browsers. There are many parts of this application that look alike - although those systems are not combatible between each others, there must be a way to share the key parts between each other.
Unfortunately there is not much information on the web about this issue, thanks in advance.
I've voted to close because the question is too broad, but here is some general information to help you develop more specific questions:
There are any number of ways to do what you're asking for. But generally you'll want an API capable of servicing all of your clients (the term API is being used very generally. It may not be a simple REST API you're looking for, depending on what you are trying to do). As for deploying your application to multiple platforms, you'll either need to find a library, framework, language, and/or emulator which supports UIs for all of your desired platforms, or create dedicated clients for each device, or a mix of the two. For simple HTML applications, React is one such front-end library/methodology/framework which can support multiple platforms through its various versions. You could use something such as Electron to pack up your application and make it look like a native app.
I would like to gather some metrics about usage for an Electron-based cross-platform desktop app. This would consist of basic information on the user's environment (OS, screen size, etc) as well as the ability to track usage, for example track how many times the app is opened or specific actions within the app.
These metrics should be sent to an analytics server, so they can be viewed in aggregate. Ideally I could host the server-side component myself, but would certainly consider a solution hosted by a third party.
There are various analytics solutions for the web (Google Analytics, Piwik), and for mobile apps, as well as solutions for Node.js server-side apps. Is it feasible to adapt one of these solutions for desktop Electron-based apps? How? Or are there any good analytics solutions specifically designed for use with desktop apps which work with Electron / javascript?
Unlike a typical webpage, the user might be using the app offline, so offline actions should be recorded, queued, and sent later when the user comes online. A desktop app is typically loading pages from the file system, not HTTP, so the solution needs to be able to cope with that.
Unlike a Node.js server-side application, there could be a large number of clients rather than just a single (or a few) server instances. Analytics for a desktop app would be user-centric, whereas a server-side Node.js app might not be.
Ease of setup is also a big factor - an ideal solution would just have a few lines of configuration to gather basic metrics, then could be extended as necessary with custom actions/events.
The easiest thing will be to use Google Analytics or a similar offering.
For most you'll have two major issues to solve over hosting on a website:
Electron does not store cookies or state between runs. You have to store this manually
Most analytics libraries ignore file: urls so that they only get hits from the internet
Use an existing library and most of these issues will already be solved for you.
I need to find out the performance of my application.This application works as follows-
It's a WPF windows application, which requires some data to be filled by user
On clicking Submit button, it calls WCF web services
These services save these values in DB
Which tool would be the best for this scenario?
The best approach would be having several thousands of geo-distributed real users having different Internet connection speed and using your WPF application normally. If you are not able to arrange this - I would suggest mimicking these several thousands users on protocol level. You mentioned WCF web services - go and find a web service load testing tool. For example good ones are:
SoapUI - designed for web services testing. Has some load testing capabilities. See Creating and Running LoadTests to get started.
Apache JMeter - multiprotocol load testing tool, supports web services as well. See Testing SOAP/REST Web Services Using JMeter guide.
In fact any tool which is capable of sending a HTTP request will fit.
You can use some of usual load testing tools? for example Apache Jmeter (free) or HP LoadRunner (community license for 50 free users).
Just record communication between your WPF application and WCF ( I belive it communicate via HTTP) and add needed parameters.