DEV Community: Joseph Olugbohunmi

My first attempt at Deploying a Backend Service on AWS: A Journey of Learning and Problem-Solving

Joseph Olugbohunmi — Sat, 30 Nov 2024 23:47:51 +0000

I have been developing backend services for about 3 years and have always deployed them on in-house servers. Deploying a backend service on AWS for the first time can be both exciting and intimidating. For me, the experience was filled with moments of triumph, a few roadblocks, and a lot of learning. In this article, I’ll walk you through my journey of deploying a backend service on AWS, including the challenges I faced and how I solved them.

NB: This article is also available on Medium

Why Amazon Web Services (AWS)?
I am currently building both the frontend (Android) and the backend service (SpringBoot) of a product (unfortunately, I can’t give too many details about this). After researching various cloud platforms, I chose AWS for its robust ecosystem and flexibility. For my project, I decided to use the free tier of two key AWS products: Amazon RDS for my PostgreSQL database and Amazon EC2 for deploying the backend service.

Setting Up the Database
The first step was setting up the database using Amazon RDS. I configured the instance with PostgreSQL and ensured it was running properly. To test the database, I used DBeaver, a reliable database management tool, to connect to the RDS instance. After verifying the connection and running some test queries, I was confident that the database setup was solid. I proceeded to provide the database URL and credentials in the application properties file.

Launching the EC2 Instance
Next, I focused on the service deployment. I launched an Amazon EC2 instance running on a Linux machine and configured a security group to allow:

The service port for external requests.
The database port for internal communication.
SSH access for managing the server.

Using CLI commands, I connected to the EC2 instance via SSH from my local terminal:

chmod 400 /path/to/key.pem
ssh -i /path/to/key.pem ec2-user@<EC2-public-DNS>

Once inside the EC2 instance, I installed the necessary dependencies (Java in particular), copied the jar file and deployed the service:

sudo yum install java-17-amazon-corretto
scp -i /path/to/key.pem my-service.jar ec2-user@<EC2-public-DNS>
java -jar my-service.jar

Testing the Service
Once the service was up, I tested it using the public URL provided by AWS. Tools like Postman and the Android app I developed were invaluable. I integrated the URL and verified the service’s functionality by sending and receiving data. I was thrilled to see all endpoints working perfectly, with data being stored correctly in the database.

The Unexpected Roadblock and the Fix
Just when I thought I had everything figured out, an issue cropped up: the service became unreachable whenever my PC was turned off. This was puzzling because I assumed the EC2 instance would remain accessible independent of my local machine. After some troubleshooting and research, I realized that there was a problem with how I had configured the instance’s networking and persistence. By applying the correct adjustments, I ensured that the service was fully reachable regardless of my PC’s status. Here’s how I resolved it:

Ensured the EC2 instance was running:

aws ec2 describe-instances --instance-ids <instance-id>

Made the service persistent by creating a systemd service file:

sudo nano /etc/systemd/system/my-service.service #This opens a text editor to create the file

Added the following content to the file:

[Unit]
Description=My Java Application
After=network.target

[Service]
ExecStart=/usr/bin/java -jar /path/to/my-service.jar
WorkingDirectory=/path/to/my-service-directory
StandardOutput=inherit
StandardError=inherit
Restart=always
User=ec2-user  # Change this to the user running the app if different

[Install]
WantedBy=multi-user.target

Saved the file and exited the editor (Ctrl+O, Enter, then Ctrl+X in Nano).
Reloaded the systemd daemon to recognize the new service, start the Java application service and enable it to start automatically when the EC2 instance boots:

sudo systemctl daemon-reload
sudo systemctl start my-service.service
sudo systemctl enable my-service.service

Checked the service status:

sudo systemctl status my-service.service # An "active (running)" status indicates that the application is running successfully
sudo journalctl -u my-service.service # Checking the logs for troubleshooting

After those changes, I confirmed the service’s availability by using the Android App when my PC was turned off, and it worked as expected!

Lesson learned
Deploying a backend service on AWS for the first time taught me a lot, including:

The importance of testing every component individually before integrating them.
Understanding AWS’s networking configurations and security group settings to allow only necessary traffic.
Ensure critical services restart automatically and don’t rely on a local machine for accessibility.
Staying calm and persistent when troubleshooting issues.

Conclusion
AWS is a powerful platform for deploying backend services, but like any tool, it has a learning curve. My journey from setting up RDS and EC2 to solving accessibility issues was challenging but was a fulfilling experience that combined technical skills with problem-solving. It also enhanced my understanding of cloud architecture. If you’re just starting with AWS, don’t be afraid to make mistakes — they’re part of the learning process. Here is an additional resource that you’d find helpful in estimating the cost of deploying your solution on AWS.

Feel free to share your thoughts or experiences in the comments. I’d love to hear how others have tackled similar challenges!

In-App Authentication Made Easy With Biometric API

Joseph Olugbohunmi — Mon, 03 Jul 2023 09:14:30 +0000

In Android Apps nowadays, there are various forms of user authentication we get to implement such as login, verification, transaction approval and so on. Traditionally, we would authenticate users with emails, passwords, OTP and the like but what if we can authenticate a user with the security token they already use on their device such as fingerprints, face, iris, password, PIN, or pattern?

With the release of Android 10 (API level 29), a new Biometric API was introduced to help Android developers seamlessly authenticate their users with Biometrics or device credentials (password, PIN, or pattern) already registered on the device. This feature is also backwards compatible, down to Android 6 (API level 23). Integrating this library is pretty straightforward and can be done in 4 simple steps.

NB: This article is also available on Medium

Now the four simple steps…

Step 1: Add the dependency
In the App's build.gradle file, add the dependency to download the library's artifacts.

dependencies {
    ...
    implementation "androidx.biometric:biometric:${current_version}"
}

At the time of writing this article, the version was 1.1.0

Step 2: Check if the device can perform Biometric Authentication
Do this check in onCreate() of your Activity or onViewCreated() of your Fragment.

private fun canAuthenticate(): Boolean {
    val biometricManager = BiometricManager.from(requireContext())
    return biometricManager.canAuthenticate(BiometricManager.Authenticators.BIOMETRIC_WEAK) == BiometricManager.BIOMETRIC_SUCCESS
}

if (canAuthenticate()) {
  // initializeBiometricAuth()
}

Before now, we could just use biometricManager.canAuthenticate() but that has been deprecated for the one mentioned above where we have to pass in a type of Authenticator.

Step 3: Instantiate BiometricPrompt and build PromptInfo

private fun initializeBiometricAuth() {
        val executor: Executor = ContextCompat.getMainExecutor(context)

        val authCallback = object : BiometricPrompt.AuthenticationCallback() {

            override fun onAuthenticationSucceeded(result: BiometricPrompt.AuthenticationResult) {
                super.onAuthenticationSucceeded(result)
                showToast("Success!")
                // proceed
            }

            override fun onAuthenticationError(errorCode: Int, errString: CharSequence) {
                super.onAuthenticationError(errorCode, errString)
                showToast("Error occurred: $errString")
            }

            override fun onAuthenticationFailed() {
                super.onAuthenticationFailed()
                showToast("Authentication failure")
            }
        }

        val biometricPrompt = BiometricPrompt(this, executor, authCallback)

        val promptInfo: BiometricPrompt.PromptInfo = BiometricPrompt.PromptInfo.Builder()
            .setTitle("Authentication")
            .setSubtitle("Subtitle")
            .setDescription("Short description")
            .setNegativeButtonText("Cancel")
            .setConfirmationRequired(true)
            .setAllowedAuthenticators(BiometricManager.Authenticators.DEVICE_CREDENTIAL)
            .build()
}

BiometricPrompt can be constructed using 3 parameters; the context, an Executor and the AuthenticationCallback. AuthenticationCallback is an abstract class that has 3 methods; onAuthenticationError() - called when an error occurs, onAuthenticationSucceeded() - called when authentication is successful and onAuthenticationFailed() - called when authentication failed. Any of these methods can be implemented based on your requirements, but of course, onAuthenticationSucceeded() is very important.

While building BiometricPrompt.PromptInfo, you can provide any relevant information such as title, subtitle, description, and so on. Before now, we could just call setDeviceCredentialAllowed(true) but that has been deprecated for setAllowedAuthenticators() mentioned above. This method makes it possible to authenticate using a password, PIN, or pattern. Please note that when setAllowedAuthenticators(DEVICE_CREDENTIAL) is called, you cannot also call setNegativeButtonText().

Step 4: Authenticate the User
Finally, you can call the authenticate method, passing in the PromptInfo object to authenticate the user.

biometricPrompt.authenticate(promptInfo)

This will display a Dialog with the provided information, now you can seamlessly authenticate a user in your App.

The Biometric API can also be used to perform other cryptographic operations. For advanced topics relating to the Biometric API, you can have a look at the official documentation.

Thanks for reading! If you have any observations, kindly share your thoughts in the comment section. You can also reach out to me via Twitter or LinkedIn.

Implementing Splash Screens the Recommended Way

Joseph Olugbohunmi — Sat, 19 Nov 2022 12:04:04 +0000

Do this in four steps only

With the release of Android 12 (API 31), a new SplashScreen API was introduced to ensure there is a standard in how Android Apps are launched. This means that using the traditional Splash screen approach will result in unexpected behaviours if your App is installed on Android 12 devices (or higher). But not to worry, implementing a Splash screen using this new API can be done in 4 simple steps. Worthy of note, is the fact that this API is backwards compatible which means it can as well be implemented on Android 11 and lower. You can easily migrate your existing Splash screen implementation to conform to the new recommended way (we will dive into that much later).

NB: This article is also available on Medium

Now the four simple steps…

Step 1: Add the dependency
In the App's build.gradle file, add the dependency to download the library's artefacts

dependencies {
    ...
    implementation "androidx.core:core-splashscreen:${current_version}"
}

At the time of writing this article, the version was 1.0.0

Step 2: Create the theme
In the styles.xml file, create a new theme (any name is fine) and set its parent to Theme.SplashScreen or Theme.SplashScreen.IconBackground

<style name="SplashScreenTheme" parent="Theme.SplashScreen">
    <item name="windowSplashScreenBackground">@color/colorWhite</item>
    <item name="windowSplashScreenAnimatedIcon">@drawable/ic_launcher</item>
    <item name="postSplashScreenTheme">@style/AppTheme</item>
</style>

windowSplashScreenBackground specifies the window background
windowSplashScreenAnimatedIcon specifies the image you want to see on the screen. In Android 11 and below, the image specified here is not animated but in Android 12 and above it comes with a nice animation and so you could use an optional attribute windowSplashScreenAnimationDuration with a recommended value of 1000 to specify the duration of the animation.
postSplashScreenTheme specifies the theme the App is expected to use after the expiration of the Splash action (usually the AppTheme)

Step 3: Add the theme to the Manifest
In the AndroidManifest.xml file, set the theme to the Application as a whole or just the MainActivity (or your starting activity).

<application
    android:name=".MyApplication"
    android:theme="@style/SplashScreenTheme"> 

                OR

<activity 
    android:name=".MainActivity"
    android:theme="@style/SplashScreenTheme">

Step 4: Install the Splash screen
In the MainActivity.kt file, call the extension function to install the Splash Screen, just before the call to super.onCreate(savedInstanceState)

override fun onCreate(savedInstanceState: Bundle?) {
    installSplashScreen()
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_main)
}

And that's it, launch the App and you should have a cool splash screen after which you should have a smooth transition into your App. The good part as I said earlier is that you can follow these same steps for any Android API level at all

What if your App already has a Splash Screen?
Well, there is a solution…

I am sure you must have seen this already in your existing Splash Screen Implementation. You may decide to suppress it @SuppressLint("CustomSplashScreen") and move on, but if your App is installed on Android 12 devices, the behaviour would be awful. But not to worry, it is very easy to migrate to the new API, it is as easy as the four steps we discussed earlier. Just follow those steps and there you go!
In addition to that, if you have a delay mechanism in your Splash Screen - maybe you are pulling some data from remote or local storage, you have to call the setKeepOnScreenCondition function on the SplashScreen object.

override fun onCreate(savedInstanceState: Bundle?) {
    val splashScreen = installSplashScreen()
    super.onCreate(savedInstanceState)
    setContentView(R.layout.activity_splash)
    splashScreen.setKeepOnScreenCondition { true }
    startJob()
}

This helps keep the Splash Screen open until the App is ready to launch the next screen and it also ensures you have a smooth transition into your App.

For advanced topics relating to the SplashScreen API, you can have a look at the official documentation.

Thanks for reading! If you have any observations, kindly share your thoughts in the comment section. You can also reach out to me via Twitter or LinkedIn.

Not a Regular Password Regex

Joseph Olugbohunmi — Sun, 30 Jan 2022 02:06:24 +0000

The password must contain at least 3 of these: a lower-case letter, an upper-case letter, a number, a special character (such as @$!%*#?&) and cannot be less than 8 characters in length.

That is the goal…

There are several regular expression patterns used for password validation based on different requirements but what if you have a password policy that is a little bit lenient and at the same time does not compromise on the security and strength of the password. There is a particular regex pattern that can achieve this (NB: I am not in any way saying this is the best password policy).

Let us have a look at the regex;

String regex = "^(((?=.*[a-z])(?=.*[A-Z])(?=.*\\d))|((?=.*[A-Z])(?=.*\\d)(?=.*[@$!%*#?&]))|((?=.*[a-z])(?=.*[A-Z])(?=.*[@$!%*#?&]))|((?=.*[a-z])(?=.*\\d)(?=.*[@$!%*#?&])))(?=\\S+$).{8,}$";

Now let us see this regex in use;

public class PasswordValidationTest {

    private Pattern pattern;

    @Before
    public void setUp() {
        String regex = "^(((?=.*[a-z])(?=.*[A-Z])(?=.*\\d))|((?=.*[A-Z])(?=.*\\d)(?=.*[@$!%*#?&]))|((?=.*[a-z])(?=.*[A-Z])(?=.*[@$!%*#?&]))|((?=.*[a-z])(?=.*\\d)(?=.*[@$!%*#?&])))(?=\\S+$).{8,}$";
        pattern = Pattern.compile(regex);
    }

    @Test
    public void test_first_valid_password_example() {
        //Number, upper case, lower case in no particular order
        String password = "13Edlpouhgfdcfvgbqb";
        Assert.assertTrue(matchPassword(password));
    }

    @Test
    public void test_second_valid_password_example() {
        //Lower case, number, special character in no particular order
        String password = "dfgjrwerdvfbghjhgfdxc90@";
        Assert.assertTrue(matchPassword(password));
    }

    @Test
    public void test_third_valid_password_example() {
        //Upper case, number, lower case in no particular order
        String password = "POIIUHGFBGNHUYF2df";
        Assert.assertTrue(matchPassword(password));
    }

    @Test
    public void test_fourth_valid_password_example() {
        //Upper case, lower case, number, special character in no particular order
        String password = "KJSrtyhgh!58E543561#";
        Assert.assertTrue(matchPassword(password));
    }

    @Test
    public void test_invalid_password_example() {
        String password = "TGsayhtgfdcsxrbfdvc";
        Assert.assertFalse(matchPassword(password));
    }

    //Utility function
    private boolean matchPassword(String password) {
        Matcher matcher = pattern.matcher(password);
        return matcher.matches();
    }
}

As seen in the code snippet above, this regex does not make any of the conditions mandatory but the user cannot submit a password that does not satisfy at least three of these conditions, and of course, the password cannot be less than 8 characters long. The fourth test case shows that the regex can allow a password that has all four combinations, while the last test case is that of an invalid password.

Now let us see the result of the tests above;

All tests passed, now some explanation;
^ Assert position at the start of the line
(?=.*[a-z]) Ensure a lower case letter must occur at least once
(?=.*[A-Z]) Ensure an upper case letter must occur at least once
(?=.*\\d) Ensure a digit must occur at least once
(?=.*[@$!%*#?&]) Ensure a special character must occur at least once
(?=\S+$) Ensure no white space is allowed in the entire string
.{8,} Ensure at least eight characters
$ Assert position at the end of the line
Also, notice that there are 4 groups of combination in the regex separated by the Alternative sign (|), equivalent to OR condition. That does the conditional enforcement. I hope this is helpful to someone out there.

Thanks for reading! If you have any observation, kindly share your thoughts in the comment section. You can also reach out to me via Twitter or LinkedIn.