For further actions, you may consider blocking this person and/or reporting abuse
For further actions, you may consider blocking this person and/or reporting abuse
Sadiq Shah -
Shefali -
Paul -
Muhammad Obaid Ullah Khan -
Top comments (2)
Hi David,
I would like to ask a few questions as I joined a company that does not have a Front-end before as a frontend dev. And this is also my first job as a front-end dev.
The current flow is Front-end team create the templates locally. Then integrate them into CSHTML (C#/.NET). Then the back-end team will change the code that will talk to the back-end.
The problem with the flow is:
So we thought about not having the back-end environment on our machines and just pass the Front-end stuffs (HTML/CSS/JS).
But the back-end team feels that we need to integrate HTML into their system and they want us to directly work using Visual Studio as it will be double work if we created templates using Atom/Visual Studio code/Grunt/Sass/ ..etc.
Also, how can they know the updates/changes to the layout if we just pass HTML/CSS/JS to them.
Thanks!
The workflow you are describing and the problems that it creates is why are thinking about the possible solutions and trying out the options.
We always - ALWAYS had two git repos. One for frontend with mostly html/js/css with just enough php or nodejs to mount it locally and load includes and so on.
The sencond git repo was the backend with the front-end integrated at a specific point in time.
How to communicate the changes in front to backend was our problem. Doing it manually requires a lot of communication and it's very fragile process, and doesn't matters if it's the back or frontend team who makes that integration.
We tried the solution I'm exposing here, that is publishing the front-end to a package manager (we choose private npm, but it can be private nugget). This requires automation, but it works well. But it's not a solution to the communication problem. We had several issues in which a feature modification involved both front and backend functional changes, very much interdependent, which lead to a complex version planning. That was a pain.
BUT, Now we are discovering that the front and the backend should be very different or be the same. Having this ficticious separation is the real problem here. It's an architecture thing. If you can publish to production one appart from the other, they should be different version and diferent repos. If not, then it's just one repo and one version to work on. Separating them causes innecesary pain.
So, we habe two types of projects now on. We have a complete SPA/PWA as frontend with a backend as JSON-API or we have only one project with front-end and back-end working in the same repo.
In the case of SPA/PWA app, the front-end and the back-end teams are separate and work with separate versioning, both deploying to production at it's own pace.
In the case of a traditional backend-rendered app, the team has both front-end and back-end devs working on the same issues/features at the same time on the same repo with the same tools.
Specifically with dotnet apps, all devs work with visual studio and windows. Windows and visual studio proficiency should be required for front-ends to work on dot-net projects. It's actually not that hard.