Reflection: Backend Implementations
What was cool/easy/hard/frustrating/intuitive/confusing?
The starter code is very helpful.
The response.ts is a bit confusing at the first stage, and eventually I just used respnse.ts once for my “reply” concept.
The dev mode and build mode produce different errors, which is very frustrating at the deployment phase before the deadline. I thought I could develop smoothly in the dev mode, but eventually, when it was built, new errors popped up. I want to know the differences between those modes.
Was there any implementation piece that felt like doing busy work (e.g., coding the same thing multiple times or coding things that you think should happen by itself)?
I think coding up the CRUDs for each concept is repetitive, but due to the nature of routes, it seems unavoidable unless we come up with another layer of abstraction. Besides, migrating our existing backend to adapt to the new frontend is a risky move. Once the backend has been migrated, the original working test pages are gone. There could be a better way of retaining both the original backend testing page and the new frontend pages.
What was the least/most exciting part of your backend experience?
I think the most exciting experience is when I realize that I don’t need too many concepts, i.e., many concepts can be combined and reduce my workload.
The second exciting part was when I realized the frontend; I eventually found out the way of using the backend rather than being confused about the design phase. The most distinct example is the map concept. In the map concept, we should think about how to display a map, but it turns out to be a document that saves the state of the map, like the last location, selected layer, or zoom level.
The least exciting part is, of course, debugging. Many problems are hidden between files and hard to position. Some new concepts that don’t have references can be challenging to design.
How do you think we can improve the starter code?
This is a very helpful starter code that can be helpful even beyond the class. So it should be worth it to provide better documents - maybe we can mobilize the full class to contribute to the starter code document. I’m interested in how the starter code abstracted the original express and Mongodb operations. It may also be helpful to provide an explanation of the key libraries used in the starter code.
The starter code can provide more reference concepts for tasks other than posting or adding friends.
The testing page can be improved by providing dropdown lists, selections, and JSON inputs.
Illustrations may be provided to help explain the structure of the starter code.
What was cool/easy/hard/frustrating/intuitive/confusing?
The starter code is very helpful.
The response.ts is a bit confusing at the first stage, and eventually I just used respnse.ts once, for my “reply” concept.
The dev mode and build mode produce different errors, which is very frustrating at the deployment phase before the deadline. I though I can develop smoothly in the dev mode, but eventually when it was built new errors pops up. I want to know the differences between those modes.
Was there any implementation piece that felt like doing busy work (e.g., coding the same thing multiple times, or coding things that you think should happen by itself)?
I think to code up the CRUDs for each concepts are repetitive, but due to the nature of routes, it seems unavoidable, unless we come up with another layer of abstraction. Besides, I felt migrate our existing backend to adapt the the new frontend is a risky move. Once the backend has been migrated, the original working test pages are gone. I feel there could be a better way of retaining both original backend testing page with the new frontend pages.
What was the least/most exciting part of your back-end experience?
I think the most exciting experience is when I realize that I don’t need too many concepts, i.e. many concepts can be combined and reduce my workload.
The second exciting part is when I was realizing the frontend, I eventually find out the way of using the backend rather than confused from design phase. The most distinct example is the map concept. I used to thought that the map concept we should actually think about how to display a map, but it turns out to be a document that saves the state of the map, like the last location, selected layer or zoom level.
The least exciting part is of course debugging. Many problems are hidden between files and hard to position. Some new concepts that doesn’t have references can be challenging to design.
How do you think we can improve the starter code?
This is a very helpful starter code that can be helpful even beyond the class. So it should worth it to provide better documents - maybe we can mobilize the full class to contribute to the starter code document. I’m interested in how the starter code abstracted the original express and mongodb operations. It may also be helpful to provide explanation of the key libraries used in the starter code.
The starter code can provide more reference concepts for tasks other than post or add friends.
The testing page can improve by providing dropdown lists, selections and json inputs.
Illustrations may be provided to help explaining the structure of the starter code.