Communication is hard. That is why agile teams have regular standup meetings. Communicating in remote teams is even harder. That is why we have tools to help us. Zoom meetings, shared calendars, and standup surveys. The great thing about technology is that much of this can be automated. Schedule a standing zoom meeting, drop a link to your public calendar, create a survey that gets send out automatically to the team every Monday morning.
The problem with automation is that it makes things mundane, boring even. We stop paying attention to the zoom meeting to get stuff done, and we start answering the same old standup questions with the same old answers without giving much thought.
Do you have any blockers?
Nope, I'm good.What are you working on this week?
Same feature, we were working on last week.
Hmm, we can do better.
I've been working on a project for Lambda School, a mostly remote, and since coronavirus, completely remote online coding boot camp. They tasked our team with creating a survey process that was more human. Instead of scheduling a survey to be sent out mechanically, our project, Apollo, would require a team leader to make a decision to send a survey out manually. They don't have to use their squishy brain to remember, we aren't monsters, they will receive a notification that they have to send out a survey request.
The reason Apollo will not send surveys out automatically is to provide an opportunity for the team leader to provide some context around the survey they are asking their team to take time out of their day to fill out. That's right, before sending out a survey request, the team leader must answer some questions themselves. Has the priority for the week shifted? Is there any new communication from stakeholders that would inform how the team answers the survey request? This valuable context can interrupt the monotony of auto generated survey requests and provide valuable insights to standups. So, Apollo would work very similar to other products, such as Geekbot, but would add an additional layer that would provide context to every survey that was sent out.
Looking ahead
Our team was excited to get started on the project, but we still had some unanswered questions and new challenges. We needed to get a better idea of the flow of the application to better understand the needs of a user. Our plan was to use Geekbot as a team and whenever we had a working MVP, use our own product for our daily standup. Mmmm, yummy dogfood. Additionally we had the challenge/opportunity to use technology we were unfamiliar with. This product would require a messaging service to push notifications to users in addition to the API, something none of us had done before. Also, we would be using a new authentication platform OKTA instead of OAUTH. Cool, time to get to work
We even have a mockup
Rolling up our sleeves
Our application was going to consist of a React SPA powered by a Java Spring API. One of the first features I worked on was a multi-step form component that would allow the user to configure a survey to send out to their team. It wasn't long before we needed data to feed our components with, so I moved over to the back end to get our endpoints working.
Models and Services and Controllers, Oh my!
Ahhh. The smell of Java in the morning. We implemented our models based on our database design and then began crafting the resulting JSON to fit the needs our of clients. We spun up the necessary endpoints; GET's POST's, PUT's and DETELE's. Everything was running smoothly until it came time to protect the endpoints and only allow access to Authorized users.
Until this point my experience creating API's was to Authenticate the users ourselves. This project called for us to use OTKA to handle Authentication leaving us free of the responsibility of owning the users information, and only having to worry about Authorizing the endpoints.
Luckily, OKTA had good documentation and there were several starter project on Github we could pick apart and learn from. When we began the process of integrating OTKA into our app, there was a gaping chasm of unknown ahead of us, but in the end, it was a relatively simple process.
The OKTA process in a nutshell.
- The client application prompts the user to enter their login information into an OTKA form.
- Upon success, OTKA returns a JWT token with their authorizations. *When the user makes a request to the API, the client application also sends the token
- The API, upon receiving the request with a token, forwards that token to OKTA, confirming that the token is indeed legit.
- Profit!
We were able to get step 1 and step 2 working quickly, so now its time to configure our API.
How to talk to OKTA servers?
We were using MAVEN for our project manager and OKTA provided a plugin. Easy peasy so far.
<dependency>
<groupId>com.okta.spring</groupId>
<artifactId>okta-spring-boot-starter</artifactId>
<version>1.4.0</version>
</dependency>
Next, we needed to configure our Spring Security to look for the JWT token.
@Configuration
public class OktaAuthSecurityConfig extends WebSecurityConfigurerAdapter {
@Override
protected void configure(HttpSecurity http) throws Exception {
http.authorizeRequests()
.anyRequest().authenticated()
.and()
.oauth2ResourceServer().jwt();
}
}
So far so good, but where do we check the token? We can set that up in our application.properties
spring.security.oauth2.resourceserver.jwt.issuer-uri=https://auth.{ourUniqueDomain}/oauth2/default
Aaaaand. That's it. No, really. That all.
Now, lets use this token with our endpoint.
Lets create an endpoint that, what else, says hello to the user.
@GetMapping(value = "/greet",
produces = {"application/json"})
public ResponseEntity<?> greetUser(Authentication authentication) {
String greeting = "Hello, " + authentication.getName();
return new ResponseEntity<>(greeting,
HttpStatus.OK);
}
Whew, now lets see if it works. Lets hit our endpoint in Postman.
We did it!
Where does that leave us. We have a front end that can grab a token and pass that token to our backend. Our backend can validate the token and serve data to the user. Our users can create surveys for their teams, users can join a team, a leader can send out the survey they created the team with or even modify the survey on the fly, team members can answer that survey and see everyone else responses. That is a great start, but our product is not done.
We still want to implement comments, so that further discussion can take place on each survey response. Leaders should have access to reporting based on survey answers. Aaaand, we still need to tackle our messaging service. We once again face a great unknown of how to implement such a thing. Cool.
...maybe that will be a future article.
[Update]
I decided not to write another article, but instead post the update here. So how many on the new features on our todo list did we ship? None!
Our app needed a lot more polish than I thought. Between testing, writing documentation and styling, we hade our plates full for the past 4 weeks getting our hacked together app working.
We focused on using our app daily and boy did that really show how broken our app really was. We really overestimated the progress we had made. For example, once we started using the app we realized that creating a survey had app breaking bugs. If you attempted to edit the default questions, it would break the whole process and you were not able to send the survey. Also, our design was not unified. Each programmer simple made design decisions as we built the components. That made the design.... unique.
So, I learned that getting the app functional is only half the battle. There is so much more work to be done to get the software in a state that can be shipped. This will help me in the future estimating how many hours projects will take and give me a better idea of the project lifecycle and where a project is in any particular state.
Until next time!
Top comments (0)