Python is actually the first decision we made in our stack selection process. The entire dev team is familiar with the language and more importantly, it is the language of choice for most of the leading machine learning research and applications. Another thing that we considered is that using python allows us to more easily hire developers in the future. Python is generally the kind of language in which it is really easy to get something started with minimal effort, which is ideal for us given our short timeline
We are planning to choose Docker since it will allow us to build and install libraries and dependencies with ease. Its extensive use in the world will be helpful to provide us with useful discussion boards. This will be the first time any member of the dev team will be using Docker as part of their application. Given the limited readings, we have been able to do about it in the time we had, we a really excited to get to work with it. It seems to have a lot of potential that we would like to explore as a team. Another reason is that our dev team currently only has access to Windows machines and we want our application to be system agnostic. Using Docker will also help us limit the number of CI minutes our application requires.
Overview: To put it simply, we plan to use the MERN stack to build our web application. MongoDB will be used as our primary database. We will use ExpressJS alongside Node.js to set up our API endpoints. Additionally, we plan to use React to build our SPA on the client side and use Redis on the server side as our primary caching solution. Initially, while working on the project, we plan to deploy our server and client both on Heroku . However, Heroku is very limited and we will need the benefits of an Infrastructure as a Service so we will use Amazon EC2 to later deploy our final version of the application.
Serverside: nodemon will allow us to automatically restart a running instance of our node app when files changes take place. We decided to use MongoDB because it is a non relational database which uses the Document Object Model. This allows a lot of flexibility as compared to a RDMS like SQL which requires a very structural model of data that does not change too much. Another strength of MongoDB is its ease in scalability. We will use Mongoose along side MongoDB to model our application data. Additionally, we will host our MongoDB cluster remotely on MongoDB Atlas. Bcrypt will be used to encrypt user passwords that will be stored in the DB. This is to avoid the risks of storing plain text passwords. Moreover, we will use Cloudinary to store images uploaded by the user. We will also use the Twilio SendGrid API to enable automated emails sent by our application. To protect private API endpoints, we will use JSON Web Token and Passport. Also, PayPal will be used as a payment gateway to accept payments from users.
Client Side: As mentioned earlier, we will use React to build our SPA. React uses a virtual DOM which is very efficient in rendering a page. Also React will allow us to reuse components. Furthermore, it is very popular and there is a large community that uses React so it can be helpful if we run into issues. We also plan to make a cross platform mobile application later and using React will allow us to reuse a lot of our code with React Native. Redux will be used to manage state. Redux works great with React and will help us manage a global state in the app and avoid the complications of each component having its own state. Additionally, we will use Bootstrap components and custom CSS to style our app.
Other: Git will be used for version control. During the later stages of our project, we will use Google Analytics to collect useful data regarding user interactions. Moreover, Slack will be our primary communication tool. Also, we will use Visual Studio Code as our primary code editor because it is very light weight and has a wide variety of extensions that will boost productivity. Postman will be used to interact with and debug our API endpoints.
We initially though we would use Django because it seemed to have a lot of the things we needed out of the box. After a bit of research we realized that using Flask would be a better option since it is more flexible and would be lighter for our purposes. Having set up our REST api using Flask we believe that we did make the right decision. We found that the flexibility of Flask along with the many extensions available for it to be very appealing. We were able to add the functionality we needed without much difficulty thanks to the quality of the extensions and their documentation.
We decided to use React for our front end. We initially thought of using vanilla JS but during our planning future-proofing our application was a concern. Though we want to keep our app lightweight, prioritizing that now but ensuring a rewrite as our app expands, is not something we wanted to do.
Out of the current top web frameworks we went with React because of the team's familiarity with it. Additionally, the facts that React has been around for so long and has a large community made us more confident that we'd be able to get the support we need.
A huge component of our product relies on gathering public data about locations of interest. Google Places API gives us that ability in the most efficient way. Since we are primarily going to be using as google data as a source of information for our MVP, we might as well start integrating the Google Places API in our system. We have worked with Google Maps in the past and we might take some inspiration from our previous projects onto this one.
Heroku is one of the leading cloud platforms and it is the ideal candidate for our workflow. It will provide us with the Heroku is one of the leading cloud platforms and it is the ideal candidate for our workflow. It will provide us with capabilities of instant deployment which will be really helpful to us in publishing the early stages of our product. It also provides vertical and horizontal scalability which is going to be of real importance to us in the future.
In terms of Business Tools we chose
Slackbecame the main communication channel among our team due to its popularity, integrations with other tools, and ease of use.
Google Hangoutswas chosen as the go to video conferencing tool because of its ease in setting up free team video calls and free pricing for our use.
This post is a bit of an obvious one, as we have a web application, we obviously need to have
CSS in our stack. Though specifically though, we can talk a bit about backward compatibility and the specific approaches we want to enforce in our codebase.
HTML : Not much explanation here, you have to interact with HTML for a web app. We will stick to the latest standard:
CSS: Again if we want to style any of our components within he web, we have to use to style it. Though we will be taking advantage of
JSS in our code base and try to minimize the # of CSS stylesheets and include all our styling within the components themselves. This leaves the codebase much cleaner and makes it easier to find styles!
Babel: We understand that not every browser is able to support the cool new features of the latest node/JS features (such as redue, filter, etc) seen in
ES6. We will make sure to have the correct
Babel configuration o make our application backward compatible.
Material UI (MUI): We need to make our user interface as intuitive and pretty as possible within his MVP, and the UI framework used by Google will provide us with exactly that. MUI provides pretty much all the UI components you would need and allows heavy customization as well. Its vast # of demos will allow us to add components quickly and not get too hung up on making UI components.
We will be using the latest version of
create-react-app which bundles most of the above along many necessary frameworks (e.g. Jest for testing) to get started quickly.