This is a Lambda Labs Capstone Project designed for homeowners. It allows a homeowner to enter their address and then answer some key valuation indicators and receive a more accurate valuation for their home than they can get from standard Parcel Data algorithms. This project also provides a dashboard with several useful tools for homeowners to utilize.
Front-end Deployment: https://myhouse-myhouse.vercel.app/
Back-end Deployment: https://labs12-real-estate.herokuapp.com/
Wireframe: https://balsamiq.cloud/snv27r3/put06ds/r2278
- User authentication using Amazon Web Services Amplify + Cognito
- Allow user to enter address and get an initial low/high valuation for their home.
- Allow user to answer questions about their home's finishes and then receive a more accurate valuation.
- Provide onboarding tour to familiarize user with homeowner dashboard.
- Overview page to give an at-a-glance view of data we've collected about the home.
- MyHouse Profile Page which allows user to provide a story about their home, recent upgrades, keep track and/or change their parcel data and home finishes data, upload a backdrop image, upload a user profile image, upload images into a gallery, the ability to click on the image in the gallery and have a modal open.
- Valuation playground page which allows user to select possible upgrades they could make to their home and see how that upgrade will positively affect their home's valuation.
- Mortgage calculator which allows user to input current mortgage amount, length of the mortgage and interest rate and receive a calculated monthly payment with the number of months required to pay off the mortgage.
- Design studio which allows the user to select different rooms within a home and see hundreds of professional images of that room for design inspiration.
- Settings page which allows user to change user profile image, name, e-mail associated with the account and change the password associated with the account.
| Anthony Venturini | David Lam | Jordan Stoddard | Gabe Samaniego | Peter Murphy |
|---|---|---|---|---|
 |
 |
 |
 |
 |
 |
|
|
|
|
| Peyton Runyan | Quinn Dougherty |
|---|---|
 |
 |
| |
|
With its vast eco-system and modular nature React is a great choice for developing the front-end of our project.
React Hooks simplify working with React due to use near exclusive use of functional components versus class components. Also, because logic can be shared, using React hooks results in smaller package sizes, which maximizes efficiency. It also allows us to abstract out a lot of local state logic keeping our component files smaller, easier to debug and more scalable.
With a global store and the ability to separate the concerns of our reducers Redux was a profoundly excellent choice for state management throughout our application to reduce state-driven bugs and share needed state throughout our deeply nested and organized component tree.
SCSS AKA SASS is a styling compiler, however, using node-sass allows us to inherit all of the functionality of the sass styling compiler without having to run a compiler on our local machine during development.
We chose SASS as a methodology for our styling in order to be able to keep styling organized in various partial files, the ability to use mixins, variables and to keep our React component file syntax easier for humans to read.
Our front end was deployed using Zeit. Zeit is a serverless cloud deployment experience which makes Continuous Deployment a breeze by connecting to our github repository. Some of the great features we took advantage of: Zeit only re-builds the parts of your application that have changed. No matter how large your repository. Zeit makes our code blazing fast: cold, hot and in-between. Our deployment is decomposed into small units of execution, all built, deployed and executed independently. Instead of deploying a large server, we deploy lots of small functions that look and act as one.
Minimize friction. Maximize security. Speed up our cloud.
Each incoming request yields a unique thread of computation in the cloud. When our deployment is not actively receiving traffic, our server stays quiet. Instead of worrying about servers uptime, tedious CPU and memory allocations and scaling algorithms, we just think about our code. Scaling doesn’t need to be complicated or expensive.
For a full list of all the third-party npm packages we used in the build of the app please visit this file
AWS Amplify + Cognito allows us to manage and control our user pool along with federated ID's for full authentication, security and polish for the end user. It also gives us scalability as our AWS API can handle 1000 calls per second.
GraphQL has many advantages, one of the big one's for us is it's integration with AWS Amplify. This allows us to build small cloud-based server instances for each user account, significantly increasing the speed of API calls that we make. Additionally, GraphQL allows for speed of development, as prototype development is much faster than REST by defining a schema, which becomes the model.
GraphQL allows for a robust integration process since data is expressed by a schema our server-side developers don't have to try to merge or enrich records on request requirements. GraphQL also comes with added features such as subscriptions, access control, monitoring and error handling. Our GraphQL server provides multiple services including a caching layer, authorization rules, and access traceability.
Node.js offers a single free codebase that is fast, easy to learn, and offers multiple modules. Collaborators can quickly get up to speed and easily modify and maintain the code for longterm stability.
Express.js allows us to code and customize the back-end to our liking, and gives us more control on what and how the back-end handles requests.
There is very detailed documentation available for each. There also widespread community support for Node and Express.
- Saves the necessary data in an efficient way
- Allows for easy queries through JOIN support
- Allows for very easy deployment
- Has a great community around it and is future proof / very independent of new trends
Amazon S3 stores static files for our app. These files include the property photos and user profile images that users will upload themselves. Their cloud storage services are secure and reliable, so our users can be assured that their data will be available when and where they need it to be. Amazon S3 is also easily scalable should the app demand higher request rates. For more information, see the Amazon S3 Documentation.
You will need to create an environment variable to make Unsplash API calls.
Steps to create secret and env variable:
-
add now dependency, in CLI: yarn add now.
-
choose the now user or team that secrets will be created under, in CLI: now switch
-
create now secret, in CLI: now secret add my-secret-name my-secret-value **run "now secrets ls" in CLI to list all secrets
-
create env variable and assign secret value to env variable, in now.json:
"build":{
"env":{
"REACT_APP_UNSPLASH_CLIENT_ID": "@my-secret-name"
}
},
**REACT_APP_ in front of env variable name is required
- access env variable:
process.env.REACT_APP_UNSPLASH_CLIENT_ID
In your backend, create a .env file that includes the following:
GOOGLE_API_KEY
- Access env variable:
process.env.GOOGLE_API_KEY
This library uses Jest for testing. For the server side, we make use of Supertest, and for the client side, we make use of the React-Testing-Library.
Front end tests can be run by moving into /src and running yarn test.
Back end tests can be run by cloning this repo moving into the root folder and running yarn test.
You can learn more about our GraphQL API here.
You can learn more about our data model here.
You can read our Express/Postgres server documenation here
So often with software development we think that coding is the more useful exercise when it comes to building an application. For our MyHouse app we took a different approach. It was our closely held philosophy that if we made a major commitment and investment in planning that it would result in a far more cohesive and organized iteration cycle. This proved to be true.
We spent 48 hours at the beginning of this project doing nothing but coming up with a long-range plan for how we would build the app, broken down by one week sprints prior to ever writing a line of code.
Due to our extensive planning and organized development strategy we actually completed what we anticipated would take 5 weeks in 3 short weeks. Due to this we had to have a Stage 2 planning session where we spent the majority of a day planning what features we could implement with our remaining 2 weeks before project deadline.
Our Technical Design Document AKA Product Canvas is 30 pages long and goes into excruciating detail upon the execution of features, challenges we would potentially encounter, the stories of how our users would interact with the features, the competitive marketplace and much more.
You can view the planning document here.
Contributions are welcome. If you choose to contribute to this project, you agree to abide by our Code of Conduct. Please create an Issue if there is a bug or feature request you are interested in adding to the project. If you would like to implement the pull request for this Issue yourself, please request permission in the Issue commentary and affirm from a Maintainer that you can proceed. Once confirmed, assign yourself the Issue in Github.
Pull requests are made via the git feature branch workflow described here. Once you are assigned the Issue, you can clone the repo locally, and begin working on the feature branch.
As you implement tests, please ensure you are running tests in both the server and client as described in the testing section. If you are implementing new features, please introduce well thought-out unit/integration tests as needed to ensure the feature works properly. Please also ensure you are running eslint using our config, and eliminating any linting errors before attempting to create a pull request. Please also run Prettier using our config, to ensure you are meeting the formatting standards for this project.
Once your feature has been finished, please use git push -u origin *feature-name* to create the branch on the remote repository, then create the pull request in github. As part of the pull request, please fill out the pull request template. Once completed, you may create your pull request. A review from a contributor and ultimate merge approval by an admin will be required. If there are requests raised in the review, please address them.
Thanks for your interest in MyHouse; we look forward to your feedback & participation!
—Anthony, David, Jordan, Gabe, Peter, Quinn & Peyton