Symfony 2 : Best practices - symfony

I would like to have a return on your experience concerning Symfony 2 projects :
Has anyone experience putting all of the projects inside the same enveloppe (each project is a bundle for example). why is it bad ?
Another solution : put the vendor folder somewhere on the server and point to it in all Symfony 2 projects (that means there is no vendor folder in the projects). What do you think about that ?
Thank you

Answer 1
It is bad because you will have a single config for each project, so a single database user etc. Not to mention best practises. There is nothing stopping you doing this, but it has bad news written all over it.
Answer 2
If you put the vendor folder somewhere else on the server you will not be able to have different versions of external libraries per project, which is actually important.
If you have common services that more than one project use then I would consider setting up APIs for each services so other projects can access it. OR you could import that bundle.

Related

Locations where Blade components are being registered in Laravel

So, I have inherited a Laravel 8 project from the previous developer who decided to leave for a greener pasture. And I see all this blade components everywhere, (x-this, x-that) and I have also created a few. I have used make:component command and I can see the components being generated both in `App/Views/' and 'resources/views'. That's great.
Now, there are other components, which the previous developer have created that I can't figure out where where these components are being registered at. They are not in the App directory, not in the service provider boot, there's no custom vendor in the composer.
So, I think the obvious question is, where else should I look for?
Those may be anonymous components. Anonymous components does not require any registration. So check resources/views/components folder.
For more info:
https://laravel.com/docs/8.x/blade#anonymous-components

One Solution, two WebForm Projects - accessing a page in one from the other. VS2019

I don't think there is an answer to this one but I'm often wrong, so fingers-crossed I am this time too.
(1) In Visual Studio 2019 I have one Solution consisting of two Projects, both WebForms.
(2.1) Project1 stores book information (but that's not really relevant).
(2.2) Project2 logs to a database any exceptions caused by Project1. It has a single logFilter.aspx page, used to view those exceptions.
(3) I've added a reference to Project2 in Project1 but this isn't about sharing code, so that's not really an issue either.
(4) My question is, when I navigate to Project1 in a browser, is there any way I can access the logFilter.aspx page in Project2?
(5) Right now for example, I have to change the Solution's Properties to make both Projects "startup projects". Then I can access them both separately - in separate browser windows - like so:
(5.1) https://localhost:44340/bookPage.aspx (Project1)
(5.2) https://localhost:44389/logFilter.aspx (Project2)
(6) That works fine on my local machine during development. But I really don't see how it could work once I've deployed the lot to my web hosting company's IIS (at www.Project1.com for example) on the Internet.
(7) I could add the logFilter.aspx page to Project1. But then I would have different versions of it dotted around all my future projects.
(8) I've searched Microsoft Docs and StackOverflow but the few answers I've found seem to be MVC-related. This post does seems to provide an answer by adding a key to web.config like so:
<add key="WebsiteURL" value="http://localhost:2030/" />
and then using:
Response.Redirect(ConfigurationManager.AppSettings["WebsiteURL"] + "SRF-GeneralInfo.aspx");
I'm no expert but I'm assuming that I wouldn't have that Port information once I'd deployed it to a web hosting company's web server on the Internet.
The answer here suggests that you either make one project the child of another or that you use virtual folders on IIS which I doubt I would have access to.
Strange, as I would have thought this would have been quite a common practice for developers to want to do. Still, any thoughts anyone has would be most welcome.
Thanks in advance,
a setup that might work better is that you have a solution with two projects. Project1 is the webapp BUT PROJECT2 is a library.
Now when you get an exception on project1 you can call the class/function what you might need in project2 and log the information.
future projects (3,4,...etc) can still reference project2 for logging purposes.

Symfony 4 and Microservices

Say I'm going to create few microservices: Alpha, Beta, Gamma.
In terms of Application structure using older Symfony version like 2, I'd create a bundle for each service, but bundles are no longer recommended in Symfony 4. So... Should I create separate repositories for every service or still create a bundles in a one App?
If you have different microservices, as in different applications, you will not need bundles. You can keep them in different repositories, but a common practice is to use a so called mono-repository. As the name suggests, with a mono-repository you keep all of the projects in a single repository. This has the benefit that changes spanning all projects can be done more easily and in sync. The drawback is that it requires more effort when managing and might cause additional overhead when building and deploying as it will not be easy to see which service has changed so must likely you rebuild all of them. There are a few books and presentations on mono-repositories you might want to check out. In short, Symfony does not restrict how you manage your services. You can have a single repository for all projects or multiple repositories.
If you want to serve all "services" through the same application, even without bundles, you can do so by using namespaces to separate the logic, e.g. for controllers:
my_app
- src
- Controller
- Alpha
- IndexController
- Beta
- IndexController
This should work out of the Box with the default configuration and even if you deviate you can make things like argument resolvers work by just pointing the configuration to the correct folder. Obviously this will require you to make sure that code is not shared between services should you ever want to extract them into their own application. There are some static code analyis tools that help you with keeping your architecture clean, i.e. make sure Alpha does not use code from Gamma and vice versa.
If you want to separate the apps more clearly by doing something like this:
my_app
- src
- AlphaApp
- ...
- BetaApp
- ...
You can still do that but it will require more manual work and the recipes will not work anymore, requiring you to do manual changes to most configurations and moving around files. How to do it depends on whether you want a shared kernel or a separate kernel for each service, but if you go that route I recommend keeping separate projects in the same repository, as it will probably yield cleaner results and be less work.
You can still create bundles in symfony4 though its not recommended by best practices. see https://symfony.com/doc/current/best_practices/creating-the-project.html

symfony architecture for multi customer application

I have a server, lets say www.myserver.com and i want to host a php symfony application for several customers.
For example customer 'abc' and 'xyz' I will have 2 separated database abc and xyz
Now, I want my customers to access like this:
www.myserver.com/abc
www.myserver.com/xyz
I'm a newbie at Symfony, my application works when calling www.myserver.com/abc/app_dev.php its in development
I have routing problems for the home page, and I dont see how to specify the database, because the parameters.yml files seems to be shared
Thanks for hints
Regards
Had the similar issue some time ago. What I had to do is to have:
/client_1 (Client1 app dir)
/client_2 (Client2 app dir)
...
/web
/client_1 (Client1 web dir)
/client_2 (Client2 app dir)
...
This way, your have separate apps which share the same codebase (src) but also have separate logs, config, etc...
But please, reconsider the decision to have this. I learned too late that I should not have done that way. By that time, it was too late to do anything. The reason was that some of the clients requested "special" features which other did not.
Hope this helps...

symfony 2 REST and JS (ember.js) client

I made a simple REST API bundle with Symfony 2 and now i want to use ember.js as a client.
I made a new bundle for it (ClientBundle). Where should i put the js files? Into
the ClientBundle/Resources folder under public/js?
app/web under public folder
somewhere else
what is the best practice / your favourite folder structure?
The best practice is to put the client code into a separate repository and use JS specific tools for its development.
Just because you can put them into a single repository doesn't mean you should. Imagine what a mess that repository will become if/when you add other clients like Android, iOS, and so on.
We put the client JS under Bundle/Resources/public/ and have a separate frontend and backend bundle. We just published a sample distro to show how this is organized here:
https://github.com/ucsf-ckm/symfony-emberjs-edition
Currently the answer would be to store the assets in the /web directory. Source
If you intend the ClientBundle to be reusable across different projects you may have, you are best served by placing the files into the ClientBundle\Resources\public\js folder.

Resources