Discussion: BACKEND technologies #2
Comments
|
Backend needs to be "node" with whatever set of deps people need. At this stage (MVP), I'd avoid adding a lot of other services until we need them (e.g., db). |
|
Should we use some kind of framework like Express or node would be enough? |
|
I'd suggest that we get some sort of a baseline going before we start seeking higher level technologies. Like we discussed in class, a simple system that produces static HTML pages based on feed data is a good starting point. Looking through npm, there are a number of existing technologies that can help us get started. For example, when I think of data manipulation in node, I immediately default to JSON. Some light digging lead me to feedparser. We can use something like this to produce Javascript objects from the feed streams, and pull specific attributes from those objects to render a basic HTML page. Even plaintext would be fine... just get something on the screen. Our "backend", at least for now, can just be some cached JSON files, and perhaps a text file with the list of feed URLs we want to grab content from (the complete list from the wiki might be a bit too much to start with). From here we can start thinking about configurations, such as minimal wait time, cache limits, or the feed properties we want to cache. After we get a feel for grabbing, parsing, and storing feed data in the node environment, we can discuss what sort of frameworks we can use to make it more robust. The URL file might evolve into some sort of API that serves up user-submitted feeds rather than parsing everything from a giant aggregate text file. What does everyone think? I'll have to do a bit more research on RSS/Atom parsers in node, but that's at least one bit we won't have to code from scratch - there are a bunch out there that already exist. |
|
I'm with @jerryshueh, let's start with something simple, maybe using http, and dotenv for simple config files. Also, it'd be interesting to start adding labels so we can tag issues and PRs as mentioned here, and we could even use the wiki to add documentation (technologies/modules/libraries we want to use, versions...). I think right now we don't have access to the wiki and can't add labels, maybe @humphd can help us with that. |
|
All for labels. We could also make use of GitHub's project management functionalities, such assigning Milestones to MVP features (which can function to label/categorize Issues, as well). |
|
Since the discussions seems to be closing in at Node, maybe we can put in a basic server file. I can do that, if agreeable. Another thing to consider is which package manager we want to use. We're all familiar with npm, but from most of the projects I encountered in the last month, yarn is pretty popular too. |
|
Before writing anything, I think it'd be a good idea to make a decision on these:
|
|
Some great ideas in here. Let's discuss more on Thursday and break this down into separate bugs. Too much happening in this one issue that isn't actionable. My thoughts on the above:
There's a whole bunch of separate issues here that can be filed. Great to see so many of you jumping in with ideas! |
|
Jumping onto the labels discussion, it would be best to start that early, and I think that could be filed under another issue itself. While it may not be direct work on the project, keeping the list of issues easily indexible will be fairly crucial for an active team of 50+ people in terms of organization, and I think should be high priority before we really start going. |
|
I think this is well in hand now in follow up issues/prs that address specifics of the above. Closing in favour of what's happening there. |
# This is the 1st commit message: reset eslint rules, refactored code to fit # This is the commit message Seneca-CDOT#2: Added jQuery to eslint
Fixed some errors found in email tester Fixed Linting errors Fixed linting errors Seneca-CDOT#2 Fixed linting errors Seneca-CDOT#3 Fixed build errors Fixed tested to ensure resolve is correct
Fixed some errors found in email tester Fixed Linting errors Fixed linting errors Seneca-CDOT#2 Fixed linting errors Seneca-CDOT#3 Fixed build errors Fixed tested to ensure resolve is correct
# This is the 1st commit message: Set up ESLint for image service # The commit message Seneca-CDOT#2 will be skipped: # Set up ESLint for image service
# This is the 1st commit message: Set up ESLint for parser service # The commit message Seneca-CDOT#2 will be skipped: # Fix typo in posts_url with docker-build-and-push.yml # The commit message Seneca-CDOT#3 will be skipped: # 2.8.2 # The commit message Seneca-CDOT#4 will be skipped: # [satellite]: use Satellite from npm registry (Seneca-CDOT#3220) # # * Use Satellite from npm registry # The commit message Seneca-CDOT#5 will be skipped: # Set up buildx before running containers in e2e tests for cachine
# This is the 1st commit message: Set up ESLint for parser service # The commit message Seneca-CDOT#2 will be skipped: # Fix typo in posts_url with docker-build-and-push.yml # The commit message Seneca-CDOT#3 will be skipped: # 2.8.2 # The commit message Seneca-CDOT#4 will be skipped: # [satellite]: use Satellite from npm registry (Seneca-CDOT#3220) # # * Use Satellite from npm registry # The commit message Seneca-CDOT#5 will be skipped: # Set up buildx before running containers in e2e tests for cachine
# This is the 1st commit message: Set up ESLint for parser service # The commit message Seneca-CDOT#2 will be skipped: # Fix typo in posts_url with docker-build-and-push.yml # The commit message Seneca-CDOT#3 will be skipped: # 2.8.2 # The commit message Seneca-CDOT#4 will be skipped: # [satellite]: use Satellite from npm registry (Seneca-CDOT#3220) # # * Use Satellite from npm registry # The commit message Seneca-CDOT#5 will be skipped: # Set up buildx before running containers in e2e tests for cachine
# This is the 1st commit message: Set up ESLint for parser service # The commit message Seneca-CDOT#2 will be skipped: # Fix typo in posts_url with docker-build-and-push.yml # The commit message Seneca-CDOT#3 will be skipped: # 2.8.2 # The commit message Seneca-CDOT#4 will be skipped: # [satellite]: use Satellite from npm registry (Seneca-CDOT#3220) # # * Use Satellite from npm registry # The commit message Seneca-CDOT#5 will be skipped: # Set up buildx before running containers in e2e tests for cachine
Part of the MVP features is to determine what technologies to use. This is a discussion on what technologies to use for the backend. We should be able to create a poll so everyone can voice their opinion.
The text was updated successfully, but these errors were encountered: