Appointment API features that should exist — #2
--
Firstly I should tell you why I’m creating an appointment service. In the first post (I need scheduling / appointment service — #1) that I shared I said I have a project that needs scheduling service because my app focuses directly on dieticians in the first place. And consultants who consult dieticians need appointments and dieticians need to set their available time slots through the calendar. So this is the “why” of this project.
How to define features?
This is the hardest question to ask because at first you should know the product or the project that you work and you’ve to define the features with that scope. If you lose your scope everything may go crazy. The project may include too many features, tweaks, or workarounds that are not necessary. It can put so much responsibility to check and that’s a quite important problem to avoid. At first, we’ve to decide what is our MVP (Minimum viable product). This should be the main goal. So with this, I thought I had to define product-level features and infrastructure/software-level features. As a software developer putting so many infra/software features into a project is my limbus.
I really love to play around with new technologies. I’m trying to add more and more new things to my project and at some point, I can’t start working on product features. It’s really annoying and in my opinion, it’s a tech guy’s procrastination. The product stays there, and the project stays there but the tech stack is world-renowned, and without the product renowned stack is useless.
And also putting so many non-required or not required for now kinda features in the product is also may kill your vibe. Because putting so many features to the product at the start may cause burnout even thinking about the roadmap.
And this time I decided to use all the tools that I already well know and put only MVP features to the product.
Software / infrastructure tools
This is my happy place to write and decide but this time I’ll only focus on MVP so I’ll stop myself about it. (I’m not sure if it gonna work but at least I’ll give it a shot).
- Go language
I’m a mobile developer but I really love to write Go. I’m confident about writing the backend with Go. I already write too many simple, intermediate backend apps so it’s a good starting point and not too showy. - Nginx
I start using it like 5–6 years ago with my hobby projects, websites, etc. For me, it’s easy to use and most importantly easy to understand. - Let’s Encrypt
SSL protection is required (not required when I start developing the project) and Let’s Encrypt is right up one’s alley. With certbot so easy to configure. - Docker
As I said I’m a mobile dev and I’ve shallow knowledge about infrastructure but to handle environments Docker is the way. And already I had knowledge of handling “dockerizing” things. I’m not writing my own Dockerfile(s) from scratch I don’t have that level of knowledge but I’m mostly using open-source ready-to-go Dockerfile(s) and I’m changing them through my needs. - MySQL
I need the database and that’s it. It’s possible to use NoSQL options like MongoDB (I’ve knowledge about it I used it a lot of time) or I can go with PostgreSQL (I used few times). But I believe my product doesn’t require NoSQL approach it may be very valuable but if you don’t need then that’s it it’s not valuable for you. And PostgreSQL is a very strong and solid approach but I didn’t use it. So understanding may take time and that time will steal my MVP product time. - Redis
I’m still not too sure about it to use but for good-level caching for non-change data, it may be ok for this project. - RabbitMQ
I’ll not go with only one monolith structure I’ll use so many things with microservices and they need to communicate and handle events. Like sending emails, sms, notifications, etc. So RabbitMQ for the win. And I know I can use also Kafka but I don’t have any knowledge except theoretical I never use so I do not have any practice with it. And with Go using RabbitMQ is so easy for me. - And all other things may appear on the way
I may forget to put a few other things into software tools. But within this roadmap, I’ll not gonna put too many things that are experimental to me. But on the way, the product and project may require other things.
Product Features
This chapter is a little bit tricky because I never create any product that covers scheduling/appointments. But the first attempt will gonna MVP so I’ve just thought about the necessary parts of the product. Thinking big for a product is good but starting to take a big bite may cause problems like putting too much work on shoulders, poorly estimated deadlines, and more. Keeping this in my mind I did think few key features for the product.
- Notifying
Calendar owner and client notification are key features otherwise no point to create an appointment if we don’t remind both sides. - Handling country-based holidays
At first, I’m planning to use it with my main project and it’ll only cover Turkiye so at first, I’ll not add other countries but with this feature adding any other country will be easy. - Only API Approach
The first phase of the app will be only-API and it’ll not include any UI. In the first phase, I’m not thinking of my appointments serving as a full product it’ll gonna just be a side feature for my main project. - Time slots
Users will gonna select and create personal time slots within the week same as all other appointment products. - Meeting Durations
Users can decide the meeting durations specifically for every day or hour. - Meeting Selection
The calendar owner also can create a meeting for clients so the owner can decide on meetings. - Calendar Integration
I still do not fully want the integration with calendars but it needs to be in the product in the first phase. So I’ll put Google, Microsoft, and Apple calendar integrations.
Conclusion
Determining the feature of the product and listing the software tools may look easy but for creating a good MVP project you’ve to think twice or more. Because it can be less than what’s needed or it can be too much work for the first phase of the app.
I’m still not fully OK with these bullet points for product features and software tools but at least I have a kick-start position right now.
What is next?
I’m planning to build a development environment and I’ll try to share posts about outlining the building environment.
This post first appeared on my blog at https://taluttasgiran.com/2023/02/appointment-api-features-that-should-exist/
