I'm wondering if I could get some opinions on whether this development project would be new and useful, or if it has already been done before.
I've been researching an idea that I have to create a premade solution for a "Dynamic Server-Side Mobile Template" solution. In my previous job I was tasked with maintaining multiple mobile clients, each of them having a custom UI skin. Normally this ends up requiring a lot of developer time when clients request UI changes or updates. My goal is to design a system that requires minimal developer input and allows designers complete control over the UI, including:
Ability to update content any time
Version control (push new template designs to client, roll-back to previous versions)
No need for developer input for design changes
What I'm brainstorming is a server side service module which is capable of providing templates on demand using RESTFul web services. The server would provide an HTML input function that would decompose any HTML page to a component tree. The component tree would then be saved to the database and displayed for confirmation & editing.
The server would be responsible for:
Decomposing any HTML page into its' template components
3rd party files such a JS, CSS referenced by path
Displaying HTML component tree for debuging and editing purposes
Saving template component details in the database with versioning
Providing template on demand (via JSON or XML) through RESTFul API
The client could be written using mustache and easily ported to the various mobile devices using the various offshoots (iOS, Android, etc). This thin client would simply send a request to the configured URI designated by the server. The URI would return all template information using mustache syntax, and this would be used to dynamically build the UI on demand. The client could also save the UI configuration and reload only when a new version is released.
To summarize, the client would be responsible for:
Requesting template data (JSON or XML) from predefined URL
Rendering template using mustache, assuming version not already saved.
I would love to start this as an open source project if the demand or need is there, and I'm not re-inventing the wheel. So far I've found similar concepts but none seem to be fully dynamic.
Related
The current project is a Single page application developed in Vue. As of now, the content is pretty much static but some data is available via REST APIs.
Now the ask that came up is to maintain the uniformity in terms of design, utilize the Header & Footer menu ( along with HTML & CSS structure) as-is in SPA from Drupal which serves static pages of the other app. There is no correlation between these two web apps.
I have read articles on headless CMS on how they serve the content to the frontend, but since this is a SPA and not Server-side driven, keen to know how to make this happen.
Of course, exposing via REST is an option but it will not be a great UX.
Kindly let me know your views on how to approach this better or what are various options that can be thought of.
Robin
You'll have to hit endpoint at some point from your Vue app.
Either compile regularly the application and consume it as part of the build process so it's static and bundled or make it dynamic by consuming the endpoint via JS.
So there are multiple solutions I can think of,
Make an SSR Node js script which will generate the header & footer and place it in index.html placeholder as a part of the build script.
( Downside is: - Frequent production update based on the changes in Drupal end. )
Make SPA as Server-side render and Respond with updated index.html.
Have an endpoint that will give the menu content assuming the common HTML structure at Drupal & SPA app.
Please let me know if there is a better approach to this.
Thanks
I'm an android developer and about two years and recently I've been thinking about building web applications. So I started researching about spring boot and everything is great. Then, I came across this thing called template engines (thymeleaf) which by definition separate your code from presentation.
What is confusing me is how can a backend server have html? should the presentation be handled by html, css and javascript in the front end? I even saw tutorials where they actually type in html code in their controller as return values.
My understanding is that the backend server exposes APIs for the frontend to use by using AJAX and the frontend will manipulate this data and present the information on the screen, why would a backend provide html code?
THank you
the frontend will manipulate this data
What front end? You mean the JavaScript code in the HTML page? Where did that come from? Oh yeah, the server.
It is the server that serves the HTML pages to the client, as well as any .js and .css files.
The server could provide static pages, and anything dynamic is handled by JavaScript. Or, the server could dynamically build the HTML page, using ... you guessed it ... a template engine.
You generally don't want JavaScript to build the page initially, just to use JavaScript for handling any dynamic behavior. Some pages don't even need any dynamic behavior.
Unless of course you're thinking about single-page applications (SPA), where there is only one root HTML page, and everything else is built client-side with JavaScript and AJAX calls, but most web applications are not SPAs.
Thymeleaf replaces JSP by providing HTML pages using a template engine. The controller requests the HTML file and Spring Boot provides that template after building it using the Model provided.
Thymeleaf is great because it allows you to rebuild templates on the fly. Lets say for example you're showing a users points to them on the front end, but maybe the points increase or decrease.
What you can do is build the template in the background using a Model. The Model reference is magically provided to the template provided which parses it.
#RequestMapping(...)
public String request(Model model) {
model.put("points", 5);
return "my-template.html"
}
Then use the Thymeleaf language to provide your object to the HTML file to be processed in the engine during runtime.
<html..>
<head>...</head>
<body>
<h1 th:text="${points}"></h1>
</html>
Spring Boots Template engine will build this in the background and present it to the user, but it will show the actual points to the end user! Hope this helps a tiny bit.
I know this question has been answered pretty effectively so far, but I want to add my two cents in as I work with Thymeleaf often.
The easiest way to think about a template engine is that it allows some dynamic development of html based on information passed to it by the controller method. This allows you to put logic in that normally wouldn't exist, or say display a certain section if a user is perhaps logged into admin.
If web pages were houses, html is the frame, css is the walls, Javascript is the lights and electricity, and a template engine would pretty much just be the architect designing the plans on the fly before the frame was built based on desires of the buyer of the house (user inputs).
OK, newer Apps and websites may just load/boot/open once and then pull or push data via AJAX requests, this is good, it saves traffic and it is fast.
But it has not always been like this and some Frameworks still don't build everything on small requests. Spring in Java or Symfony in PHP are MVC Frameworks and use template engines to build pages. This may sound a little outdated but there is still a lot of websites using this.
And if you build a web app for a customer with slow PCs or other devices and the page contents are performance heavy you might want to do as much work as possible on the server so that the user does not have to wait for long. And also you can cache the rendered pages. There is even server side rendering of react pages to e.g. make the initial page load faster...
With Java and Spring I did just use JSP I don't know thymeleaf. Just use what you like and maybe what is most supported/documented.
And building websites like this does not mean you cannot use AJAX, but if you use templates you need to think about what makes sense.
What is confusing me is how can a backend server have html?
The "back end" must have HTML, because that's what's delivered to, and rendered by, the client.
It may just be that the back end "server" is just a CDN delivering, say, an HTML/JS SPA, but there's still something delivering content to the browser.
That said: server-side rendering is still a thing, and has had a resurgence lately--a React app may have its initial rendering done on the server so again the client gets a page rendered with both HTML and associated data, and then starts acting like a normal SPA.
My understanding is that the backend server exposes APIs for the frontend to use by using AJAX and the frontend will manipulate this data and present the information on the screen, why would a backend provide html code?
Because something needs to run the JS to access those APIs.
Some history:
Browsers used to suck. JS used to be a neat add-on, sites were relatively static, and essentially all rendering was done on the server. The back end would get data from wherever it got data from and generate complete HTML pages, and there was little happening on the client side other than some form fields, maybe some validation, and that was about the extent of it.
I have started working on a project that needs a re-write. So, instead of doing a big bang release
we have decided to use Strangler Pattern which means the following
The current application (stack details below) will be running as is under the existing domain https://app.com
The existing (and new) features will be re-written in a new stack (details below) and deployed in parallel to the existing app (under the same domain https://app.com)
The requirements are
The end-user always works with the same domain https://app.com
Any existing feature migrated to a new app or a new feature is available by the under the same domain https://app.com
The stack and architecture of the current app is
HTML files with hardcoded data
CSS files
font files
PDFs
images
flash files
among other things.
Thee application is static. It has no database. It makes calls to other 3rd party APIs but does not have its own database (other than the files, and the images)
It sits under a directory and is served by running a web server (Apache) on a private dedicated server.
The stack and architecture of new re-write will
Use React or Gatsby
A standard build system that generates the static files
The data (PDF, Images) hosted somewhere else
Flash files (until we figure out a better way)
Given these requirements, I thought of having 2 versions of the app using some sort of load balancer such as Nginx and serve the URL patterns using a proxy.
For example
a request coming to https://app.com/productPage.html goes to existing app deployment (assuming it is not migrated)
a request coming to https://app.com/profilePage goes to existing app deployment (assuming it is migrated)
Now, considering this situation, I want to ask the following question
Is this approach looks sane? Are there better ways to deal with this situation?
How to implement such a reverse-proxy based system (considering Nginx)? (or if there is a better way)
I would love to hear out ideas and any resources/books/github that can help me learn and implement this.
Thanks a lot in advance!
I would recommend to create a v2 of pages that has been migrated to new functionality. And all links to the page should be updated to point to v2.
If anyone has done bookmark to old links, then those pages can simply redirect the user to the v2 ones by simply redirecting them using JS - window.location(url_of_target_page);
I have a web service written in Java using Struts2, struts controller returns jsp pages, now I want to rewrite frontend using react components, what is the best way to start?
TLDR, you can easily announce to your stakeholders, that it'll take few months/year or more depending on how big is your application/team.
This is huge shift from web application architecture point of view. Struts2 + JSP is doing HTML templating on back-end. So data are injected into HTML on server and HTML is also format that is returned from server.
On the other hand, React is client-side HTML templating library. So it is expected to communicate with server via AJAX calls and reading data (in JSON or other format) and inject that data on client using React.
So this will not be easy change. You would need to decouple all your JSP data inject points into services and expose them as JSON data via controllers (taking into account changing of authentication mechanism, input validation, ...). After that refactoring you can start moving your JSP templates into React (most probably JSX). But on that path you realize that you may want to use some UI state management (e.g. Redux). You also discover that you want to structure your components into more composable way than most of old JSP templates were. Didn't mention you'll need to also port over some JS that was embedded into these JSPs. Said that, you may end up wiping out all the JSPs altogether and creating UI application from scratch.
You will also discover on that journey stuff like JS testing, UI build pipeline, asset bundling and more goodies of modern UI web development, which will add to overall refactoring.
Almost all guides available online talk about working with JSON that is fetched from the server. We are taking an alternative approach to this.
We are generating HTML markup with the data server side, at least on initial page request (mostly for SEO reasons), and then trying to get Backbone.js to takeover from there (for infinite scrolling, or making future POST requests, as an example), a la Twitter.
I have searched online for some guidance on this for over two days now but have not found anything besides this:
SEO And Accessibility With HTML5 PushState, Part 2: Progressive Enhancement With Backbone.js
Am I missing something very obvious or is there a truly clean way of doing this with Backbone and/or Reactjs?
If you're using React, I recommend react-quickstart.
The tools it comes with make server-side rendering very simple, and the client picks up the DOM and makes it interactive.
A minimal React project template which combines:
react-router-component to provide HTML5 History routing and navigation
react-async to create "asynchronous" React components
express to serve pre-rendered React components, assets and provide API
browserify to provide module system for a browser
npm to install and manage server-side and client-side dependencies