I've been reading about how nuxt can generate a static site when a client makes a request to view the website. We are planning to build a headless cms to migrate the database with the data the website needs. This data will only be changed when you save it in the headless cms.
My question is since this data will only change when it is changed in the headless cms. Isn't it possible to just generate the site when it is modified from the headless cms, and then serve that site to the client? To reduce server costs.
Is it possible to do this with nuxt? Or are there any possibilities to do this?
We are planning on using Firebase as a backend.
There's nothing explicitly preventing Nuxt from being rebuilt each time you change an item in your DB. The part that matters is how you tell your app to rebuild itself.
By far the simplest way is using some sort of "build hook". See Netlifys docs here for a quick overview of what they are. However, this only really works if you're using a headless CMS that can send hooks on save, and a build provider that can trigger builds using those hooks.
You will absolutely save on server costs using this sort of method, but beware: if you have a lot of user generated content triggering builds, your build cost can easily outweigh the server costs. You also need to be aware that builds generally take a few minutes, so you won't see instant changes on your site.
The other option you have is foregoing static site generation in favour of SSR, which can dynamically load and render your content, completely avoiding the need to build every time a new DB change is made. This is what I'd consider the best alternative if you do indeed have a lot of user generated content.
It's hard to give any further advice without knowing the specifics of the CMS or build provider though.
We currently have an application that is usable by several clients, it is used to download and store data from our application that they have on their environment.
We have a need to pass this application over to a developer but at the same time, we need to protect our code. The way that I see it working is that we would like to some how consider our current app a framework, allowing another app to be created on top of it, but the app may have its own screens, but re-use some of the built-in screens.
Is it possible to protect our app in such a way with out rewriting everything into protected DLL's? Or should we just suck it up and share our code with consulting firms that want to build these types of apps for our clients?
If your proprietary code is entirely focused on downloading and storing data. You could create an online REST api that returns the data over the internet. The other developer could then just request the data from your servers using an HTTP call.
However if your code needs to be client-side, the only real thing you can do is compile a DLL, and even then that can be decompiled.
I am setting up a DTAP environment for Google App Maker. Google App Maker enables working in a singe file very well, however there is one use case that I would like to simplify.
For each deployment I need to "know" certain things in the back end script. Things like the ip address of the SQL server, or usernames and passwords. This information needs to be retrieved fast and often, given the stateless nature of google.script.run.
The best solution so far is a settings form, combined with google drive tables and caching. This works, but it is not simple, and things could fail easily. The other approach is hard coded and linked to the deployment url. This is fast and simple, but also means that all the credentials are in the source.
I am looking for a better solution. Apps Script used to have the script properties. Is there a similar option in App Maker, with a UI to maintain the settings.
There is no built-in UI to manage script properties, but App Maker's runtime (Apps Script) provides API to perform CRUD operations on it:
PropertiesService.getScriptProperties().setProperty('testKey', 'testValue');
...and you can 'easily' build the UI on top of this API. In answer for this question are highlighted major steps to achieve this: Google App Maker how to create Data Source from Google Contacts
Here is a feature request for the first party support. You can up-vote it by giving it a star:
https://issuetracker.google.com/issues/73584947
We have software developers (PHP, SQL) and web designers (HTML, CSS, JS, Foundation, Bootstrap) in our team.
A typical scenario: a software developer implements the business logic while the design is done by another person.
Problem: whenever there are changes in the frontend design, the designers have to send new designs to developers, they have to track changes and modify the sources.
Question: what tools/approaches are available to allow designers to work with the Twig templates directly, and apply changes to HTML/CSS/JS without backend developer help (without Symfony and LAMP installation, if possible)?
Or on a higher level - what is the best practice to separate backend and frontend development in Symfony 2?
Or on a higher level - what is the best practice to separate backend
and frontend development?
The frontend team, can work in the templates and send you the markups and then the backend developers will decorate it with the data, that is how it is usually done.
BUT:
The best approach that you can take to separate totally the 'Backend' work from the 'Frontend' work is doing it. :
Create your backend logic to serve the data at demand (Web service / API), instead of serving the views, send a response with a clean body that contains only the data in a readable format, like json objects.
Then the frontend developers can make the corresponding request to the web service to get the data and decorate their templates with it.
The only thing that you need to do is to provide them with the URL that will provide the data for the template that they are working, and the expected output/format that they will be receiving when requesting that url, so they do not even need any server working, they can mock your response while they are testing / creating the view.
Personal opinion:
I think that even for simple applications, this approach is great.
Why?
If you create your backend as a Web Service / API, then it would be easy to expand it, at some point your application would be used by third parties applications, or you just want to create a native mobile application version, or whatever. If that is the case you don't need to re write nothing.
Short History
I've seen huge proyects that were supposed to serve a web page, then it become populars and it ended with more usage from third parties than the web itself and were not prepared for that. They ended developing a web service, with half of the functionality for the third parties apps, and for each functionality that they added to the web service layer they used more code, more testing, and so on..
Come on, still writing?
Talking about web development, you can keep your frontend guys focused on display the data, style, and events of the page, while the backend guys keep focused in adding new features, so no one needs to distract the other side team just because they don't know how a tool from one side works, that for me worth the time that is saved.
The only "best practice" that I could recommend is to talk with the web designers and understand their needs.
Because TWIG is almost pure HTML
This is just plain wrong. TWIG may look like HTML but it's all about the data. Ask your designers if they would be happy seeing something like this in the browser instead of actual data:
List of Products
{% for product in products %}
{% endfor %}
Somehow I just don't think that will work for them.
I suppose there might be a tool out there somewhere that can convert TWIG into real HTML but what to use as data? If it does not match the back end data then problems will ensue.
I would suggest that you will need to teach your developers how to use composer update as well as your source control system. The database should not be a problem. You can have a single designer database somewhere that the back end folks can keep up to date. Someone else can install and configure the LAMP stack,
You could even setup virtual designer machines (perhaps with vagrant) that will be fully loaded with whatever software your designers needs for a specific project. Your developers might find these virtual machines useful as well.
The other approach is the nuclear option. Don't use TWIG. Your back end turns into a web api and only deals with data. No back end generated html at all. Your designers now have complete control over the front end. Bit radical perhaps but it does seem to be the way the industry is moving towards.
Twig is related to Symfony controllers for the "data".
If your designers wants to modify a html part of the twig templates, they can do directly into templates.
If they want to add additional elements which are related to specific data, the should work with backend developers in order to update controllers code and populate this data from backend to front-end part.
If you use symfony to provide only data (JSON based on lot of AJAX Requests from front-end) I think that designers can work alone with interface and mock JSON data in their local installations without using symfony code.
There is no "best practice" to separate backend and frontend development in Symfony 2, simply because it uses the MVC pattern, which in itself separates buisiness logic from views. All your views are gathered in a single directory, and the only job your designers will have is to display the data. Controlers and all the backend stuff is gathered some place else and is invisible to them.
Symfony is not an obligation (although it is the perfect tool for what you want to do right here), but I'd recommend you choose a framework that implements the MVC pattern, because it is the cleanest way to develop, and assures your code to be maintanable a long time from now.
I will share our solution/practice out of PHP, which completely separate the front-end works from the back-end and our designers and developers are separated in different departments, they are connected by redmine's tickets, but they do not need to communicate to each other in most cases, and also their work will not interact with others in most cases.
Out solution is based on java/javascript, simply we developed our own framework to combat with the issue about separating front from back. Currently we have two independent frameworks for this issue, one is for server side rendering by Java, another one is for client side rendering/binding by javascript, a client javascript MVVM framework.
At first, the basic idea of our frameworks is separating all the template rendering logic from the html template, thus our html templates are real pure html files, without any back-end intrusion.
The second step, our designers will complete their works on the independent html files without any consideration of back-end logic. Then at the same time, our back-end guys will write the back-end rendering/logic by separated java/js source.
Assume we have a html file like following:
<div><input name="name"></div>
<div><span id="name-preview"></span></div>
We will perform the server side rendering by java as following:
Render.create()
.add("[name=name]", "value", user.name)
.add("#name-preview", user.name);
Also we can perform the client 2-way binding by javascript as following:
Aj.init(function($scope){
$scope.data = {};
$scope.snippet("body").bind($scope.data, {
name:[
Aj.form({name: "name"}), //bind the $scope.data.name to input[name=name] in 2-way
"#name-preview" //bind the $scope.data.name to #name-preview in 1-way
]
});
});
As in the above examples, we use common css selector to describe where and how we want to render/bind our values to.
At a matter of fact, in our practice, over than 90% front-end refactoring would not need the help from back-end side. Even in the left 10% cases that our back-end guys have to fix the broken rendering/binding, the fixing would become very simple because we just need to change the target css selectors in most situations.
At last, although we implement our server side framework by Java, we believe it can be ported to any other languages such as PHP, ruby, python, etc.
The server side framework:
https://github.com/astamuse/asta4d
The client side framework:
https://github.com/astamuse/asta4js
Disclaimer, I am technical support and sysadmin for my company, not a developer. I'm not after the specifics, simply an idea if what I'd like to acheive is possible or not.
We host hundreds of instances of our in-house classic ASP legacy ecommerce software application and due to countless customisations by clients and ourselves, version management is nightmarish, custom code can't be managed and we've given up releasing new features and mass deploying bug fixes due to the inability to track who needs what patches where.
Parellel to this question I am making management scripts to better automate this though.
What however I'd really like to do is using the miniumum possible effort, port the application code (not the database) to a single code base. Questions I have:
Can ASP relatively effeciently handle connecting to different databases depending on the host header being called? I plan some basic extension to the routine, get hostheader
lookup up db credentials in metadb, set application connection string accordingly logic.
The application writes a few files to the webserver from the database for caching purposes, I'd like to handle this by emulating this behaviour by writing it to something like /masterapp/customer1/specificfile.htm then changing the references to /specificfile.htm in the code to more like /masterapp/shop name/specificfile.htm. Obviously the routines that write specificfile.htm would write to the new location accordingly. Does this seem reasonable?
Other webserver-bound store specific contents like images and csv files I need to keep working without URLs changing ideally, can ASP employ logic to redirect get requests for /images/example.jpg to either /masterapp/shop name/images/example.jpg or /shopname/images/example.jpg depending again on host header? Or could that be done via isapirewrite? (which we already use)
I think these are the biggest challenges. I don't need a complete project plan of how to implement each of these things, I just want to know if it's possible. If the answer is 'yes' I should be able to sell my bosses on the development due to saving support time and our in-house developers could hopefully manage this.
This should be possible and I have achieved similar outcomes with code developed that way from the start. As you are retrofitting this in it's going to be a lot harder, but that's separate to your actual question.
To answer your actual points:
Presumably your DB connection string is already in a application variable or settings file? If so, you just need some logic in your global.asa Session_OnStart that reads the host header and selects the appropriate DB string. This could be hard coded or you could have a "control" DB that stores sites, their DB strings file paths etc and pulls the details into the session object.
This is related to the above, pull your cache storage locations from the DB, or have a "directory name friendly" base name for each site, so you can have "/masterapp/" & Session("strSiteBaseName") & "/cache/somefile.htm"
If you're on IIS7 then you can use the URL rewrite module to handle this, if you're on IIS6 there are 3rd party tools you can get to do URL rewriting for you. Again I have done this so can vouch for it working. If you want to get really clever, you can have your master app create the rewrite files for you and "touch" web.config to get them loaded into IIS.
One "gotcha" you'll have with host headers is remember to handle www and no-www records!
You mentioned custom code as well for each site, I haven't done this in production but have tested outside an app and you can rewrite functions after they've already been declared. You can't have includes with variable names, but you can load in a text file and execute it, so there is a way to have custom functions, or changed core functions specific to an individual instance of your over-arching app.