Another problem is that a web API is an extra layer to worry about. It must be designed, implemented, tested, documented, etc. And all this is frankly a pain in the ass.
Let's say we use this technology in one real world big project. My main concern is how are we going to do testing with this. Having all code together will create a hell for creating automated test isn't it. What about code coverage how will you measure it without converting unit tests into integration tests? What about external resources? Are you going to mock backend and frontend components for the same test? What if you need real third party components in your testings? Would you use headless browsers and mocks/real backend resources to create your unit test? Are you going to create tests for backend and tests for frontend separated?
This sounds like either we would need to create files with code exclusive for backend and files exclusive for frontend which is going against the whole concept or are we going to forget about unit test and always do integration tests since frontend and backend will be coupled. Also integration tests are always more expensive, my guess is that our current concept of unit tests should be adapted to be more like integration tests. And where are we going to put the real traditional integration tests it sounds like you are going to have a layer to test those I have an idea let's call it 'backend'.
I think you misunderstood Layr. The backend and the frontend are physically separated. They can be developed and deployed independently. You can have unit tests for the backend, and if you mock your backend, you can also have unit tests for the frontend. It's no different than a traditional single-page application.
Please have a look at this example. As you can see, the frontend and the backend are two different applications with their own package.json file.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Let's say we use this technology in one real world big project. My main concern is how are we going to do testing with this. Having all code together will create a hell for creating automated test isn't it. What about code coverage how will you measure it without converting unit tests into integration tests? What about external resources? Are you going to mock backend and frontend components for the same test? What if you need real third party components in your testings? Would you use headless browsers and mocks/real backend resources to create your unit test? Are you going to create tests for backend and tests for frontend separated?
This sounds like either we would need to create files with code exclusive for backend and files exclusive for frontend which is going against the whole concept or are we going to forget about unit test and always do integration tests since frontend and backend will be coupled. Also integration tests are always more expensive, my guess is that our current concept of unit tests should be adapted to be more like integration tests. And where are we going to put the real traditional integration tests it sounds like you are going to have a layer to test those I have an idea let's call it 'backend'.
I think you misunderstood Layr. The backend and the frontend are physically separated. They can be developed and deployed independently. You can have unit tests for the backend, and if you mock your backend, you can also have unit tests for the frontend. It's no different than a traditional single-page application.
Please have a look at this example. As you can see, the frontend and the backend are two different applications with their own
package.jsonfile.