I’m in the process of building a new webapp which uses Wagtail. This is an architecture question.
There will be the standard About, Terms of Service, and Blog pages. All of which fit in with the Wagtail paradigm very nicely. The rest of the site content is location-based information about specific types of businesses. Think of a FourSquare type app. The data for these pages will be very structured, be updated via user-facing webpages and a mobile app, and be JavaScript heavy.
For the regular Wagtail pages, there may be hundreds over time. For the location page types there will be (hopefully) tens of thousands of pages that will be nested to a max of four levels.
From a site-wide feature perspective, I’m looking to leverage Wagtail features like sitemaps and Elastic Search.
My question is, should I use the wagtail Page class for my location based pages?
Pros:
Easy integration with Elastic Search and Wagtail sitemaps
Leverage Wagtail editor on the admin side.
Consistent model and api structure throughout.
Cons:
Potentially more overhead for location pages.
Need to utilize more hooks to manipulate the view output (Lots of JS, so will be inserting non-model info into the template).
Potentially limits the use of some third-party modules.
If I went the non-wagtail route, is it possible to add non-wagtail models to the search index?
Are there other issues I should consider in this choice?
Any Django model can be indexed and searched by inherit from index.Indexed and defining search_fields onto the model.
As for using pages or not, as always it depends on many things. However, it looks like it would make sense to keep your location model as such, not make it a page and expose in in the admin (either Django Admin if you need some extensions that already exists there, or Wagtail's modeladmin otherwise). Then you would create a LocationIndexPage which implements the RoutablePageMixin to dynamically serve the LocationPages. The page won't exists in the admin tree but will be reachable anyway.
Related
I'm working on a project, which has two applications, one is an admin portal where users can customize and create their profile and other one is an application which will preview the profile user creates.
All good with the admin portal, which is developed with CRA - React App. Earlier I was planning creating profile app also with React. Anyhow considering SEO and performance I'm thinking about pre-rendering the profile whenever user changes data.
This will improve the performance by considerable margin and SEO as well. SSR is another good solution, however when there are thousands/millinos of users view single profile, there will be a huge demand for server performance. So that I'm planning to work on a POC, which will create static profile with partial cliend side js functionalities for each user and store it somewhere and serve it through CDN.
I want to know two things here -
To implement this, I'm having lack of knowledge in terms of available solutions. Solutions for storage, cdn.
How can we render static pages during the data changes.
To implement this, I'm having lack of knowledge in terms of available
solutions. Solutions for storage, cdn.
Check Cloudflare CDN. But there are many other proveriders.
How can we render static pages during the data changes.
If you are using pre-rendering, You can rebuild the page assets after a profile page is updated and redeploy them.
If you are using SSR then the server load will be high but no need to redeploy (as the page is rendered at runtime from the origin server always).
I would recommend you use Next.JS support for server rendering and pre-rending instead of implementing them on your own.
I need to develop a simple social networking website which will just act as a platform for different businesses to discover each other. Each Business man/Service provider will have his own profile that he can manage and these profiles will be characterised and sorted according to their types. Basically I would need a Home Page, Profile page for each profile, Search page along with registration and login. I don't need to make any messaging module.
So for this purpose I wanted to know if using Gatsbyjs is a good idea, also if not then what are the other frameworks that I can use for a easier and faster development.
One main problem with gatsby for this use case is: Once a new business signs in and wants to create and edit a new profile, this new profile is not part of the build process. Gatsby builds only the HTML pages you know in advance. Triggering a rebuild, which may take several minutes, everytime a business edits their page is not feasible. You would have to hack something together with client-side routes which is not the intended nor recommended way of doing things.
A server-side framework like Next.js is better suited for this task. This way you can dynamically add and change the profile pages.
I am trying to create a complex CRUD React Application using Gatsby JS. The ability for the user to Create Posts, Edit Posts, Delete Posts will also need to be available. This app will have many users. We are not using a third-party CMS. Everything will be done within the Gatsby App. There will also need to be several different pages that will need to handle state, display, and sort the different posts based upon options. My question is, is this sort of project overload for Gatsby JS since it breaks the page model? Gatsby doesn't have a native way to generate dynamic routes or views, only pages. Its sort of a social networking app, is Gatsby JS the wrong tool for the job?
You can create pages "dynamically" using the createPages API.
https://www.gatsbyjs.org/docs/node-apis/#createPages
There's also a great series of videos from Scott Tolinski that demonstrate the use of this API.
However, GatsbyJS is a static static site generator, it's designed for performance and more content-based sites. The only way you're going to get CRUD functionality is through API calls from the front-end which could have some security implications that you need to consider.
As an alternative, you might want to take a look at Next.js. Same kind of idea but the pages are served by Express.js rather than just served off the file system so you have a lot more options for more dynamic sites.
I am learning MEAN Stack. I started from learning Angular(from angular.io) now I am learning node.js and express.js
My question is, if there is angular for front end in MEAN Stack then why there are views and template engines in express.js at back-end? Are they alternative for each other or complements each other? what is the boundary for the role and responsibility of these two?
I am looking forward for someone's help in clarifying of my concept for role these two technologies(express' views and angular) used in mean stack.
In order to answer your question, let me explain what is angular and what are template engines in express?
What is Angular?
Angular is a platform that makes it easy to build applications with the web. Angular combines declarative templates, dependency injection, end to end tooling, and integrated best practices to solve development challenges. Angular empowers developers to build applications that live on the web, mobile, or the desktop.
what is template engine?
A template engine enables you to use static template files in your application. At runtime, the template engine replaces variables in a template file with actual values and transforms the template into an HTML file sent to the client. This approach makes it easier to design an HTML page.
Some popular template engines that work with Express are Pug, Mustache, and EJS. The Express application generator uses Jade as its default, but it also supports several others.
So,
Angular is a framework with a templating component baked in. You use it to create Single page Web Applications which means that DOM modification is happening on the client side and the app exchange with server only data. If your concern is template it is plain HTML.
Whereas, template engines' rendered views are sent to client each time by server whenever request is made each time a new page is rendered on server and sent to the client which is Great for static sites but not for rich site interactions.
If there is angular for front-end in MEAN Stack then why there are views and template engines in express.js at back-end?
This is because not every time generating views from angular is recommended sometimes it is better to use Template Engines to generate views and send the rendered page to a client, generating views at client side has its own pros and cons and generating views at server side has its own.
Generating views using template engines (i.e. at server-side):
pros:
Search engines can crawl the site for better SEO.
The initial page load is faster.
Great for static sites.
cons:
Frequent server requests.
An overall slow page rendering.
Full page reloads.
Non-rich site interactions.
Generating views using angular engines (i.e. at client-side):
pros:
Rich site interactions
Fast website rendering after the initial load.
Great for web applications.
Robust selection of JavaScript libraries.
cons:
Low SEO if not implemented correctly.
The initial load might require more time.
In most cases, requires an external library.
So, after knowing the pros and cons, you yourself can better decide that in particular case which one is better for you. Mean Stack has provided options for developers.
As far as your question regarding the role of these two technologies is concerned, Angular is a lot more view generator only, It has features like routing, it as services two-way data binding etc while the template engines are meant to render HTML so that it can be sent to the client.
I hope you will find this answer useful.
References:
what is the template engine?
what is angular?
pros/cons
Angular is a full-fledged front-end framework that comes with its own way of doing templating, using angular-specific markup in your HTML. If you use Angular as your framework, you're more or less stuck with their way of templating within the Angular portion of your application.
Angular Features
It is a framework written in Javascript language
Manages state of models
Integrates with other UI tools
Manipulates DOM
Allows writing custom HTML codes
It is meant for javascript developers to create dynamic web pages in a quick time
NodeJS
It serves the web
It is runtime built on javascript engine in google chrome
It can be considered as a lightweight server which can serve client requests in a more
simpler way than java does
It performs communication operation with databases, web-sockets,
middleware etc.
Why we use angular for Tempting not Express/Node tempting Engine
Server-side rendering is the most common method for displaying information onto the screen. It works by converting HTML files in the server into usable information for the browser.
Whenever you visit a website, your browser makes a request to the server that contains the contents of the website. The request usually only takes a few milliseconds, but that ultimately depends on a multitude of factors:
Your internet speed
how many users are trying to access the site and
how optimized the website is, to name a few
Once the request is done processing, your browser gets back the fully rendered HTML and displays it on the screen. If you then decide to visit a different page on the website, your browser will once again make another request for the new information. This will occur each and every time you visit a page that your browser does not have a cached version of.
It doesn’t matter if the new page only has a few items that are different than the current page, the browser will ask for the entire new page and will re-render everything from the ground up.
How client-side rendering works
When developers talk about client-side rendering, they’re talking about rendering content in the browser using JavaScript. So instead of getting all of the content from the HTML document itself, you are getting a bare-bones HTML document with a JavaScript file that will render the rest of the site using the browser.
This is a relatively new approach to rendering websites, and it didn't really become popular until JavaScript libraries started incorporating it into their style of development.
See Examples HerePratical Example
Basically template engines in Express are mostly used for displaying 404 and other server error messages. I find them ideal for such use cases. Using template engines for complex front end rendering is bad and not a good practice.
Express JS is a web framework on top of nodejs http module. Whereas Angular JS is a front end framework which doesnot depend on NodeJs server to run. Conceptually both are similar in few features like routing whereas implementation is different
I have a SPA here and I´m wondering what should I do to get it properly indexed by Google bot.
I read a lot on multiple views angularjs apps (hashbanging and that stuff) but my app has just one view / controller.
Should I create an html copy for each of the items being shown and link them together?
Thanks in advance,
Ariel
In AngularJS, you can compile templates & cache them using a variety of techniques - you'll need to write a process or build into your runtime logic building these templates & binding them to data, writing them out as static files.
Google allows for special handling based on user-agent. I have a friend who says, "This was called cloaking, before Google owned Angular." This is true. You need to setup server logic that re-directs any Google-bot user agent (or other search engine agents you care about) dynamically to one of these static "Search-Bot Friendly" pages.
Although this is more work, there are obviously bonuses to being able to maintain a set of content that search crawlers "see" and a (potentially different) set of content consumed by real users.
This is also the reason why AngularJS as a client-side framework quickly falls down the rank list when search visibility is a primary objective of the project.