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.
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 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/
We are going to build something like cratejoy.com, but don't want spend lot's of time building which is already builded before for developers.
I was going through sonata and sylius, but not sure if we can build subscription based model with one of them. If yes we can, then which would be best to use? or should we just build complete custom solution, because it involve b2b solution.
What we will be building?
Basically e-commerce software like any os-commerce shopping system, but the only difference is, we will be adding subscription on each product.
So let's say, if you order a product, we will ship it to you every month to your door step.
but we are building this as service, so many people can just create their site and start using our tools to start selling there products.
I might be a little biased towards Sylius, as I work with it constantly - I've tried using Sonata bundles in projects before but failed in making use of them.
Reasons for using Sylius are that it's heavily decoupled and customizable, which is exactly what you want if you need an e-commerce solution that is not the conventional "add product to basket, pay for it once" model.
There are two approaches you can take to use Sylius: Either use the full stack application and customize it, which is the most common approach and better supported. The other approach is to install Sylius like a library rather than an application and build the application and frontend yourself, using Sylius classes and services when you need to (which is what I do).
Things to be careful when using Sylius are that it's still in beta, with breaking changes occurring between releases. Also the documentation is very incomplete or outdated (something I plan to help improve), with the exception of Resource and ResourceBundle - these packages are the most important part of Sylius and are therefore very well documented. For your project, I recommend the first option.
For subscriptions, areas of Sylius you want to look at configuring and extending are OrderBundle, PricingBundle and PaymentBundle. If you're very familiar with Symfony, this should be straightforward.
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
I'm in the planning stages for a new project involving eLearning and content management/delivery.
I've dabbled in Symfony2 before and I quite like it's flexibility and extensibility. But I have recently discovered EZ Publish is now running on the Symfony2 stack with version 5.
My question is, what does EZ bring to the table? Will it save me time and money in realising the end product? Or will it ultimately prove to be a hindrance if it is designed to be 'easy' rather than flexible?
Thoughts and suggestions are welcome :) Thanks for your time
It depends on how much of platform you will use for your custom logic.
If you will write most of code using Symfony components than you can use your bundles interchangeably in Symfony CMF, Symfony Standard Edition or EZ Publish.
If you want working CMS and write only handful of specific features independent of CMS functions than you can go with EZ Publish. But you still should write your code separated in bundles, so your custom logic is again nicely portable.
If you want to extend existing CMS features. Than you might want to go with Symfony CMF.
I would suggest to use Symfony CMF, which is the CMS for developers. EZ Publish is not totally migrated to Symfony, so you as a developer will still have to deal with legacy code. Also starting with Symfony Standard Edition to build a CMS you will have to build a lot of tools that are already built into Symfony CMF.
eZ Publish 5 brings you all the features you need when it comes to build a CMS based website. I'd say that 90% of the most important features from eZ Publish 4 have been migrated on Symfony2. You'll also get a really good admin interface.
eZ Publish 5 uses the full stack which makes a big difference when compared to others CMS like Drupal, especially if you need to build business features aside your CMS.
Also, the code quality of eZ Publish 5 is really good and tends to respect the last standards so you'll benefit from this choice one day or another : http://blog.insight.sensiolabs.com/2014/11/04/technical-debt-relevant-projects.html
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.