Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I have below applications:
a magento2 e-commence site with Restful API in docker
some nodejs micro service Restful API in docker
i have question, if i wanna to develop a ecommence + user portal frontend site, which framework i should pick? NEXTJS or GATSBY?
given that:
i have over 30000 user
I need to serve more than 10 locales, and may keep increasing
I need to serve more than 10 countries , and may keep increasing , and each of those may many different localisation setting
i have over 10 store represent 10 countries , each of them has more than 20 products, and may increasing
I do not agree with Zain Ui Hassan's answer.
With Gatsby, it doesn't matter the amount of asynchronous data your site will have, the number of pages, or the dynamic data. In the end, it is a React site with all the content already fetched and served, so it's blazing fast. Moreover, you have a bunch of official plugins that manage all your needs.
You will be able to handle a S3 AWS deploy.
Multilanguage support with redirections included and dynamic routes
CMS fetched data with a bunch of multiple CMS support (Contentful CMS, DatoCMS, Strapi, Netlify CMS, markdown files, JSON files, custom database, etc).
Lambda support.
You don't need a Node server to deploy or view a Gatsby website since it renders a static HTML, so you don't need any extra configurations, just a server, all pages are created in the build time. Next.js needs server-side customization and rendering.
In addition, it's SEO-friendly, you can easily customize your components to render (even when the page is already created) with the proper country-oriented data.
In the end, it's completely up to you, but in my opinion, you will need fewer configurations and you will have less trouble using Gatsby, due to the few and easy configurations.
In terms of community, both have great support so it's a tie.
Personally, I think that the only area where Next.js would be the better option at the moment is scalability since Gatsby, especially in large-scale projects, will increase the deploy time (up to 10 minutes, which is not ideal) but I know they are working on improving this by implementing incremental builds. I reduced my deploy time from 8 minutes to 2.
but i do want to know more, if a page path that depends on user, e.g
/myinbox/letter-from-tom-to-stanley, each user may have different msg
on their inbox, and each inbox may have different path depend on user
This will depend on your code logic rather than the framework used. Of course, you are able to achieve this both with Gatsby and Next. I'm doing similar stuff with Gatsby and I have no issues. Of course, you will need a back end logic sometimes (database stuff), but it's completely doable.
Answering your question. It's a personal choice and you can fit your specifications with both (like the other question shows). I would choose Gatsby because it's more oriented towards SEO (conversion), easy to maintain if it's well structured (data-entity in CMS, etc), the plugin support, and the fewer (minimum) server configurations since you are uploading a /public compiled folder.
Useful articles:
https://dev.to/jameesy/gatsby-vs-next-js-what-why-and-when-4al5#:~:text=JS%20is%20mainly%20a%20tool%20for%20server%2Dside%20rendered%20pages.&text=Gatsby%20can%20function%20without%20any,HTML%20page%20from%20the%20server
https://www.gatsbyjs.org/features/jamstack/gatsby-vs-nextjs
https://medium.com/frontend-digest/which-to-choose-in-2020-nextjs-vs-gatsby-1aa7ca279d8a
Gatsby is used for static websites where you don't have lots of dynamic data. If you are building complex level website go with NextJs.
Next.js has the best-in-class "Developer Experience" and many built-in features; a sample of them are:
An intuitive page-based routing system (with support for dynamic routes)
Pre-rendering, both static generation (SSG) and server-side rendering (SSR) are supported on a per-page basis
Automatic code splitting for faster page loads
Client-side routing with optimized prefetching
Built-in CSS and Sass support, and support for any CSS-in-JS library
Development environment which supports Hot Module Replacement
API routes to build API endpoints with Serverless Functions
Fully extendable
https://nextjs.org/
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed last month.
Improve this question
So basically the only major benefit implementing SSR + CSR is SEO? Because if you think about it SSR actually is slow in initial load time because you have to wait for the server to render and respond with the HTML + JS which needs a nodejs server with all the complicated configurations for production while in
CSR you receive instantly the bare bones HTML and JS (can be cached) which can just be hosted on a file bucket with no complicated server configuration, also now a days browsers / computers / phones are actually fast enough to render components quickly so initial load time is not an issue. And also you can actually do lazy loading for components.
So aside from SEO, you actually add more cons when implementing SSR + CSR.
Anyone please do correct me if Im wrong 🙏
SSR + CSR vs CSR. Cons seems to outweighs using SSR+CSR than just CST
SSR can be helpful because it will display the static content ahead of time, providing the user with a visual rather than waiting for a spinner to create the whole thing.
You will have a hydration phase, but you can skip parts of those or even not use them at all (Islands Architecture like AstroJS does or with some other packages).
SSR will also bring the SEO part as you know, which is quite important for some types of apps (blogs, marketplaces, StackOverflow etc...).
The SSR step can be rather quick, especially if using Edge Side Rendering. You can also cache it and the configuration doesn't need to be difficult (it can help with memory leaks too because you will kill it everytime), the "charge" supported by a server is not a consideration anymore
It can consume fewer resources regarding the end-user devices because no: not everybody is using the latest iPhone 14 Pro. The most common device is still a Motorola G5 or alike (in terms of raw power). Not to say that people can come from various countries where bandwidth/expensive phones are not a thing yet.
Database delays are also not a thing if they are done ahead of time and can be skipped by the client.
Again, more and more advanced configurations are feasible but it all comes down to how much you want to optimize your app and how much money you make out of it.
Nowadays, tools like Qwik, Marko, and Astro are popular because they are joining the group of cool kids shipping less JS to your visitors. It is always nice when you see how much money your business can generate with some fine-tuned performance metrics.
If you have a chill casual chat app, keep it as a SPA.
Also, not all apps need SSR/SSG. Some of them can stick to SPA (dashboard, gmail-like etc...).
One is not better than another, they all have their pro/cons. The thing is that you need to understand how to efficiently use each one of them in the best situation. And Vue/React don't do all those things in the same way too...
You can give a read to those great authors, they are quite good at explaining the performance considerations and future great frameworks (aside from the usual React/Next etc..):
https://dev.to/tigt
https://dev.to/ryansolid
https://dev.to/filrakowski
https://twitter.com/mhevery
https://twitter.com/danielcroe
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
We're developing an e-commerce application with Symfony2. It will have different features like product, sales, customer, shipping management, etc..
And it will have 3 subsystems: Web Frontend, Admin and a RESTful API.
Should we organize our bundles by features or by subsystems?
Well, it's your choice! Traditionally, if you explore the vendor bundles that Symfony comes with and the 3rd-party bundles that are available, they are organized by feature.
For example, the Sonata Project starts with a core bundle and provides features in each of the other bundles.
What you should be more concerned about when splitting your system up into bundles is finding a way to de-couple them from the other bundles so that they can be re-used in other projects with minimal modification but more configuration instead! Your best approach (just an opinion of course) will be to make all of these features individually in the bundles and tie them all together with another bundle.
You may find that answers will become subjective depending on each developer's view on the matter.
We've developed an e-commerce solution with Sf2 and at the beginning we asked ourselves the very same questions. Should we organize our bundles around entities or sub-systems(admin, front …) ?
We decided to go for the features/entities solution and we embedded the sub-system in the bundle.
What made us take this decision is the possibility to attach functionalities to the core feature.
For instance, we created bundles like product, catalogs, order, customer … these are the basic bundles that you will find in any e-commerce solution. We also implemented a core bundle that ties them up.
But some of our client may want to use more functionnalities/plugins like tracking, assets/images, reporting.
These bundles are optional and if we give our client the code of the application, I don't want him to get the code of unwanted/unpaid plugins. So the features are split up in different bundles and they're linked by interfaces and config files.
The bundles also carry the sub-system applications like the administration panel. If the client does not have the tracking bundle, then the administration panel will not show the tracking interface because it is not activated in the kernel.
I hope this will help you make you mind.
Per symfony's documentation you can organize bundles in any way you see fit. So long you stick to the coding convention, and overall good coding practices. Especially if you plan to release this bundle to the public (which might not be the case in this scenario).
That said, I would advice against organizing your project by features because the number of features will always increase over time; whereas the number of subsystems in your project is more than likely to remain constant.
Take in consideration that a new bundle, is a new sub-project to manage, if you're using other bundles or libraries like Assetic, then you would need to enable every single bundle in the configuration, so the bigger the number of bundles, the more difficult it is to manage the overall project.
So, if I were in your position, I would break up the system in subsystems. Create a bundle that exposes a RESTful API, another for the Admin, and another for the Front-end.
Structure them in a way that every bundle can live on their own, just in case you need to deploy every sub-system of your project to different servers, so that is just as easy as striping them out of the main project, and integrate them into a new one.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 6 years ago.
Improve this question
I know this has been asked a lot and I've explored the other answers, but I still have questions, so hopefully this sheds fresh insight on the debate.
A year ago I built a service scheduling web app from scratch in CodeIngniter with the following functionalities:
user management with different roles and functionalities
different backends for each user
interactive and manageable calendar for scheduling services
territory management and assignment
management for service status
reports and records
billing with authorize.net
front-end informational pages
All pretty standard stuff and codeIgniter worked great. Now, a year later, I'm revising the code. The client wants some different management features, like a CMS for the pages and to add new services and change the calculation price points, etc. I need to add new classes and code to make this work.
Over the last year I have dove very deep into Wordpress and realize that I could have built this whole app in wordpress using custom post types, taxonomies, custom fields, and expanded custom functionality though a custom plugin. In many ways, this seems like it would be better.
Pros of using Wordpress instead of php framework:
existing base with CMS, user management, familiar backend, database structure to start from, saving lots of development time
constantly updated security
stability
robustness (I know wordpress can handle this even though its intended use is for blogs)
Reasons to use a framework:
flexibility
ORM
MVC
other?
So... which is better? Do I really need ORM or MVC for this project? I feel my development efforts and client ux would be easier if I use Wordpress.
What else do I lose if I switch to wordpress?
What about combining Wordpress in a framework, or vice versa? Recommendations?
When does it make sense to use a framework instead of wordpress?
It's a fairly broad question, so here's a fairly broad answer...
Wordpress is a CMS. It's a good, flexible CMS with lots of built-in goodness, but its sweet spot is managing a site that's primarily about content, where content is very broadly defined as "words, pictures and other assets". The plug-in model lets you build/use additional functionality, and the wide user community provides lots of stability/security/scalability help.
Code Igniter is a framework that's designed for functional web apps (in practice, this usually means database-driven apps). Its sweet spot is managing complex interactions with a business domain. It is a framework for building any kind of app (including, if you were glutton for punishment, a CMS).
If your business domain is about content (and I don't think it is, based on your description), Wordpress is an obvious winner. In your case, I think you could probably build the solution using Wordpress, but it would be a real edge case - and the benefits you mention of "security, stability, robustness" would likely not apply, because you would need to build a lot of custom code. I think you'd very quickly get to the "well, it's not the way Wordpress wants me to work, but to deliver this feature, I just have to do it this way" point.
When business users say they want a CMS, they usually don't mean they want Wordpress (or Drupal, or Sitecore, or Magnolia); they want to be able to manage their site without having to go to the techies. If your site is primarily database-driven, that means screens to manage database records.
It's about structure and function in my view. Both CMS(Wordpress) and PHP Framework provide structure/functions to build your own functions. You can do the same things on CMS and Framework. They shouldn't have much difference on performance and security amongst well known Frameworks and CMSs.
However, CMS focus on Front-end (contents?), provides with ready to use CSS, Javascript (Front-end) in order to build / manage websites and web based applications easy and quick. Though, it's not very clear in structure comparing to MVC model.
Both would do the same job if you develop yourself, but in a team, framework could provide benefit.
It's only my view, I am using Wordpress a lot and a little knowledge on framework.
I use CodeIgniter and my bias is for that because you've already built the bulk of your app in it and because it seems more flexible/less pre-configured than Wordpress. I also get the feeling that CI is growing in use relative to WP with developers so CI seems possibly more future-proof, though to be fair they are both popular.
Can you make clearer you're bosses demands? The way I read what you say is that you're 80% of the way there and then are considering scraping (or at least possibly having to heavily revise) that 80% because the other 20% seem more logically done in Wordpress.
As I learn PHP more, I'm actually finding myself using even less of CI and writing more straight up PHP or actually JavaScript (for even better UX). So I guess I'm surprised to hear of someone wanting to switch from a minimal PHP/ruby/Python framework to a heavier one since most of the work is shifting to JavaScript these days.
Another key point on going towards straight-up PHP is that the number of people who know PHP dwarfs the number of people who are familiar with CI- or WP-specific syntax. So you are more likely to get help/collaborations/career advancement focusing on a solid foundation in the "mother tongue" over these minority dialects. Doing this with PHP is also having the benefit of helping me understand other languages such as JavaScript better since the level of abstraction is on the same page with php-ruby-python, whereas a framework brings in an entirely different (an in my increasing view, extraneous) vocabulary.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am in the process of architecting an application. It will be a large, enterprise class web application. Thousands of users could upload files, search large number of blog entries with chat functionality and such. It will also have mobile interface. It should be highly testable, scalable and flexible.
I have narrowed it down to three environments: pure play ASP.NET, pure play DotNetNuke (DNN) and a combination of ASP.NET and DNN. To keep this very brief, here are some 'for' and 'against' on each of the options:
ASP.NET:
for: highly scalable, supports patterns like MVC, testable, consistent architecture.
against: long development time.
DotNetNuke:
for: short development time, large number of existing functional modules and skins.
against: architecture is sealed, can't support MVC, unit testing is difficult, inconsistent modules/skins, potential upgrade issues, user experience is inconsistent due to disparate modules from different vendors, poor documentation.
So, the questions are: what do you think? Has anyone switched from DNN to ASP.NET (and, vice versa)? Have you objectively evaluated these two and what did you choose?
Highly appreciate your help. Thanks.
henry.
DNN is ASP.NET, just with a lot of the work done for you.
Also, please remember that just because raw ASP.NET has the potential to be more scalable, doesn't mean that you are actually going to built it to be more scalable. Or that you will built it well in the first place.
It comes down to a trade off between control and resouces/talent. If you have many very talented developers (like, top-10% talent), a lot of time, clearly defined requirements for your site, and consumers who will be patient while you build out the infrastruture, by all means go with raw ASP.NET.
However, if you need to build it quickly and need to be flexible, or you have limited development resources, you might have to sacrifice some of that control and unit testing and potential performance (again, the "potential" part is key here).
Based on what you are looking for, I'd recommend you go with a platform like DNN, or a million other ones line SiteFinity or Umbraco or Orchard or something like that (some of them like Umbraco give you MVC too). It gives you a lot of the infrastructure and plumbing common among a lot of sites, probably done better than you are going to do it, so that you can focus your resources on the truly unique aspects of your application.
Just stay away from SharePoint. It's evil.
I've built raw ASP.NET sites for really customized applications, which was good because I didn't need a lot of plumbing and wanted really unique funcitonality through the site. But then I've built social networking sites with DNN, which worked well because it had packaged components for blogs and forums and chat and all that stuff, plus allowed for easy skinning. I designed another application for a customer that they wanted to have a lot of custom functionality, but they also wanted to updated a lot of content and internatalized it, so we used a Umbraco for that. And right now I have a ASP.NET app that works great, but I want to add in some social features, so I'm going plug in a Umbraco or DNN site that integrates with it to host the more common social components.
I would definitely recommend DNN based on your very limited list of needed features. You can always build a custom module to meet your exact needs or modify an existing open source module as needed. You can use the MVP approach in your module development to improve the testability.
Have you considered the Umbraco CMS? It is built on .Net (v5 is MVC3). It is open source and a very robust and well supported application. It has been used for the asp.net site for example.
It has a very short development time, many modules, extremely flexible and I find it very easy to extend. For example, I rolled my own workflow, event driven publishing and have created multiple custom administration sections for managing bespoke functionality external to Umbraco.
You can use XSLT, Usercontrols or Razor to create template modules.
It has a fantastic community too.
I'm starting work on a personal site that's primarily a blog, with a section for various tech projects as small as a custom photo gallery to as large as a restaurant-review web-app. Not having worked with WordPress or Kohana before, I'm curious what the advantages are of integrating WP into Kohana (or any other framework, for that matter), and vice versa, given this situation.
I've seen bits of this mentioned here and there online, but no definite post comparing the two approaches, so I'm hoping others can pitch in here :)
I've not used this before, but kerkness has written a plugin for it: https://github.com/kerkness/kohana-for-wordpress However, it is quite old so you might want to look for something newer.
Integrating Wordpress with a framework (be it Kohana, CodeIgniter, Zend, etc.) is often sought without addressing the first and most important question: How far do you want to integrate the two at a feature level?
Broadly speaking, there are two high-level approaches to integrating any two PHP products:
1) In the PHP code, include the libraries, bootstrap scripts, etc. from both products into a script or scripts (creating a "hybrid").
As a developer you should be able to use most of the features from both products in the resulting hybrid. For example, in the case of Wordpress and Kohana, the complete result would allow you to use Kohana features (e.g., routing, auth, etc.) and Wordpress features (e.g., fetching post contents, authors, etc.).
The difficulty with this approach is competing APIs and code expectations that might make the hybrid behave unexpectedly, e.g.,
Will there be competition between the class autoloaders?
Are there duplicate function or class definitions?
How extensively can plugins in Wordpress be supported if they depend on PHP settings that the framework is going to change on bootstrap?
The first issue I would want to resolve when attempting this process is the routing, am I going to delegate fetching of posts, attachments, etc. to Wordpress from within Kohana, or am I going to have to build an interface between Kohana's router, controllers and Wordpress?
While this option is appealing because you can access both product APIs, you must be prepared to make significant changes to the application behaviour in order to allow both products to co-exist peacefully. If this sounds like a lot of work, it is because it is a lot of work!
2) Use the webserver to intelligently route requests to different products.
From your question, it sounds like you want parts of the website to load web applications that don't necessarily need the level of integration indicated above (e.g., would you really need to get Wordpress API in the review application, or the photo gallery?). If you are just looking for a way to load two applications using the same application domain, this option would be better suited because you don't need to perform much (if any) integration between the two.
Assuming you are using a webserver like nginx or Apache Httpd, you should be able to create aliases for different parts of the site to different applications.
e.g.,
http://myblog.nonex/ - points to the Wordpress installation, which in turn manages the default site (shows pages, blog posts, etc. all from Wordpress).
http://myblog.nonex/apps/review - points to the review application, which is the Kohana installation.
http://myblog.nonex/apps/gallery - points to the gallery application, which (with proper modularisation) could exist alongside the review application in the same Kohana installation.
Since you are still in the planning and development stage, I would recommend going for option 2) first - build a prototype, identify any areas where you absolutely need features from Wordpress in Kohana (e.g., would either the review or gallery application need to use the Wordpress user credentials?) and look at performing a minimal integration before creating a full hybrid.