DEV Community: Noda

Why Security Testing is a Must-Have for Fintech Success

Noda — Tue, 17 Dec 2024 10:10:40 +0000

Written by Alena Khaitsina, Head of Manual QA at Noda

The fintech sector is growing at an unprecedented pace. With more people relying on digital solutions for banking, investing, and payments, ensuring the security of these systems has become crucial. Unfortunately, as technology advances, so do the tools and techniques used by cybercriminals.

The Rising Threat Landscape

A Growing Target for Cybercrime

Cyberattacks have more than doubled since the pandemic and continue to grow in sophistication and impact. Not only is the number of cyberattacks growing, but incidents are becoming more sophisticated and dangerous.

According to the Global Financial Stability Report, the risk of extreme losses from cyber incidents is increasing. The size of these extreme losses has more than quadrupled since 2017 to $2.5 billion. And indirect losses like repetitional damage or security upgrades are substantially higher.

Third-party exposure

Cybercriminals can get around security systems by hacking less-protected networks belonging to third parties that have privileged access to the hacker’s primary target.

For example: A third-party vendor is used to manage your customers' passwords. The third-party shifted to a hybrid work model over the past few years. During an ongoing due diligence review, you discover that their information security policy has no mention of virtual private networks (VPNs) or multi-factor authentication (MFA) for remote access. As a result, your organization is exposed to information security risks and potential data breaches that can affect your customers.

Configuration mistakes

A configuration issue can be as simple as using weak passwords or a more complex problem, such as improperly set up firewalls.
Here are some of the most common configuration issues that lead to cyberattacks:

Failure to change device default configuration
Network segmentation
Not updating/patching computer software
Using Weak Passwords

Why Security Testing is Critical

Fintech products often handle highly sensitive information, including personal identification details, bank account numbers, and credit card information.

Security testing isn’t optional — it’s essential. It protects sensitive financial data, safeguards user trust, and ensures regulatory compliance.

What should be done? There are some ideas on what be implemented in the software development process according to Secure Software Development Lifecycle (SSDLC):

Vulnerability Scanning: Regularly scan your application and its dependencies for vulnerabilities using automated tools.
Penetration Testing: Regularly perform penetration testing (ethical hacking) to identify vulnerabilities before malicious actors do.
API Security Testing: Test your APIs for common vulnerabilities like injection attacks, authentication flaws, and data exposure.
Security Code Reviews: Conduct regular security-focused code reviews to identify potential vulnerabilities early.
DevSecOps: Adopt DevSecOps principles to integrate security into your DevOps pipeline. This involves automating security tests, monitoring, and patching during the CI/CD process.

The Benefits of Security Testing

Building Customer Trust

Trust is a cornerstone of the financial services industry. Customers expect their financial data to be secure and are increasingly aware of the potential risks associated with online transactions. By implementing rigorous security testing protocols, fintech companies can demonstrate their commitment to protecting customer data.

Regulatory Compliance

Fintech companies operate in a heavily regulated environment. Non-compliance with security regulations can result in hefty fines and sanctions. Regular security testing helps ensure that products meet regulatory requirements, thereby avoiding legal issues and maintaining operational continuity. Staying ahead of compliance demands also positions companies favorably in the eyes of regulators and investors.

Mitigating Risks

Security testing is an essential risk management strategy. It enables fintech companies to identify potential vulnerabilities before they can be exploited. By employing various testing methods, such as penetration testing, vulnerability assessments, and code reviews, organizations can proactively address weaknesses in their systems. This approach not only reduces the likelihood of incidents but also minimises the impact should a breach occur.

Enhancing Product Reliability

Security testing contributes to the overall reliability of fintech products. A product that is secure is inherently more robust, leading to fewer downtimes and disruptions. This reliability is crucial for maintaining service levels and ensuring that customers can access their financial resources without interruption, thereby enhancing user experience.

Continuous Improvement: The Key to Staying Secure

Security testing should not be a one-time event, but an ongoing process integrated into the software development lifecycle. By continuously testing and improving security measures, fintech companies can adapt to new challenges, ensuring their products remain secure in the face of evolving threats.

Also, security testing is not just an added layer of protection for fintech products; it is a fundamental requirement for success in the industry. By prioritizing security testing, fintech companies can protect sensitive data, build customer trust, ensure regulatory compliance, mitigate risks, enhance product reliability, and foster continuous improvement. As the digital finance landscape continues to grow, the importance of security testing will only increase, making it an indispensable element of any fintech strategy

How involve design team in testing for better user experience

Noda — Mon, 29 Jan 2024 08:48:11 +0000

Written by Elena Khaitsina, Lead QA Engineer at Noda.

Usually, the common practice in Agile teams is that every department has well-known roles and responsibilities.

For example, for the development team to work on creating code and unit tests. The business analysis team focuses on defining features that users will love, and simultaneously the design team explores the best ways to bring ideas to life through prototypes or design templates. The QA team plays a crucial role in validating the product.

However, not everything goes smoothly in the Agile process.

From my experience, the primary bottleneck often arises when conceptual ideas confront the reality of implementation. For instance, designing a feature in a tool like Figma may differ significantly from how it's eventually implemented.

Sometimes the differences were significant.

Besides checking the correct operation of created applications the guys from the QA department also verify the app views by checking the general appearance and the correctness of styles and content.

You’re almost ready to launch, but then you discover that you’ve focused on all the wrong things from the beginning: on the design phase.

In light of these challenges, a compelling idea emerges: "How can we avoid this situation?"

To address this, a potential solution is introduced – the use of Acceptance Testing by the Design team. This approach suggests involving the design team in acceptance testing to ensure that the final product not only meets functional requirements but also aligns seamlessly with the envisioned design.

Why is it so important?

We know you’re probably wondering “Why bother?”

The first and main reason is to find deficiencies between the design and implementation.

This includes not only functional discrepancies but also ensuring that the visual aspects align with the initial design.

Besides this, it helps a lot at the stage when the design doesn’t contain all the elements described in the requirements, e.g., missing buttons.

Just for notice!

"design testing is NOT the same as testing responsive design."

While responsive design testing focuses on adaptability, design testing involves a more comprehensive evaluation of the visual and interactive elements.

The second reason is to review if all design solutions work in real life. It's not just about functionality but about how users interact with the design elements in practical scenarios. This step ensures that the design not only looks good on paper but also functions seamlessly in the hands of the end-users.

Of course, the prototype can help with this in the early phase but it’s not always time or needs to draw prototypes for small features or changes.

The third reason is to get to know the application inside and out. It helps to be up to date with the functionality of the product. Also, the future design and implementation will be designed within the current features, ensuring a seamless and consistent user experience across updates and iterations. This comprehensive understanding aids not only in current testing but also in making informed decisions for future design enhancements and feature implementations.

Design testing in practice

The process of product development has remained almost unchanged.

The only additional step has been added and now the process becomes like this: when the testing phase is completed on test environments, a separate Acceptance Testing (AT) task is created. This task is assigned to the person responsible for the design of functionality.

There’s one very important thing to remember!

Design activities are an integral part of the User Story and are included in the Definition of Ready. This means that the story/features can’t be moved further along the flow. Therefore, if a design has bugs, then such a User Story cannot enter the development stage.

Next, the ball goes to the design team's side.

The design team conducts a thorough review and provides feedback to the entire team.

If needed, some changes in the current implementation are done.

After all corrections, one more round of AT is initiated.

If everything is OK – the AT is closed.

Finally, the product is ready for the real user!

Notice!

If the designs require corrections, you should do it as soon as possible and “freeze” the final version. Then, update the documentation/requirements. This will ensure development is conducted on the set-in-stone version.

Benefit from design testing

The benefits of design acceptance testing are vast. It’s not very time-consuming and it certainly adds value to the software development quality process.

There are some points:

Generate new ideas you may not have thought of before while making prototypes and/or design templates.
Feel confident in your product design decisions.
Detect errors in the test environment before the customers will see them, which means much lower costs of improving them.
Pay more attention to UX design. By clicking through the app you can check how easy it will be for real users to orientate not only to small new features but to the whole product.
Check the differences/consistencies in the general design decisions relating to content, fonts, and colors.
Testing provides necessary evidence of intuition and helps designers to alter products and services where required.

Conclusion

Everybody knows that the quality of a product is the responsibility of the whole team – not only the Quality Assurance Department. This rule also works in the Noda team

Moreover, Acceptance Testing (AT) by the Design team is not a replacement for User Acceptance (UA) testing by the QA team. Both play crucial roles in ensuring a robust and user-friendly final product.

Both are crucial in ensuring a robust and user-friendly final product.

Typed translations in Angular

Noda — Wed, 08 Nov 2023 08:28:58 +0000

How to Improve Angular Application Build Quality and Enhance Key Verification with ngx-translate or transloco

By Maksim Dolgikh, Senior Front End Developer at Noda.

Introduction

Supporting internationalization is one of the challenging topics in front-end development, everyone always adds only keys and values for the primary locale, usually English (en or en-gb), leaving translations for other languages for later.

We encountered this issue on one of our projects while implementing localization.

In the initial version, we did not configure the localization settings, completed the build, and obtained the result.

Translations by token, in case of failure, were replaced with the token name.

The hotfix for the problem is to use a fallback language (fallbackLang) when resolving translations by token.

The fallbackLang solves the issue of displaying text so as not to confuse the user, but there's still a need to monitor the presence of keys, and also involve QA to detect problems.

Many who use runtime translations fully understand the problem of, "how can you ensure that the key-token is correct and will find the corresponding translation for the current locale at browser runtime?"

I too wondered about this, but all I managed to find was an article from October 21, 2018. Typed translations in Angular.

The solution was excellent for that time, but the author uses the object directly, and native pluralization through js with the presence of ICU seems excessive.

Undoubtedly, this solution could have been improved, for instance, by making the TRANSLATION token a stream and adding an aggregator service with translations upon language change, and so on. But then again, that's a whole different story.

ESLINT - i18n-json

The situation is partly saved by the eslint plugin eslint-plugin-i18n-json, which checks the identity of the keys in json files, but it's also not enough for reliability.

Because it's a one-sided check, and it doesn't guarantee that the developer, using the current translation base, will specify the correct key, and QA will notice it if something goes wrong.

We will need to install eslint, commitlint to check changes in json, and also integrate it into pipelines if we have translations embedding from external sources.

My Proposal

What if I told you that all these checks are unnecessary?

To ensure the consistency of translations under a locale, forget about fallbackLang and missingKeyHandler, and no longer worry about the correctness of the key, can it be achieved solely with typescript?

This solution is suitable both for current implementations on ngx-translate or transloco and for new ones.

So, what requirements should the solution meet?

The application build fails if a key is missing in one of the translations.
Developers are notified of errors with an incorrect key, and there are hints about the available list of keys.
Ensure scalability by adding new translations by locale, without direct interaction with the code, but provide all checks.
Current key translations for ngx-translate and transloco work as before. They can be parameterized, and they support ICU.
Translations can be used in libraries, and they can be published as self-sufficient packages.

Secondary:

QA, through the browser console, can understand which element interacts with which key.
Exclude switching to a locale if it's not on the list of available ones.

Solution

The demonstration repository consists of:

assets - a directory with a subdirectory i18n, where translation files are stored.
libs - a set of libraries for:
- ui-actions and ui-layouts - a set of demo-libs.
- i18n-wrapper - contains entities for typing the transloco service.
- typed-transloco - a typed version of transloco with its translation file and based on i18n-wrapper.
src - directory of the host application.
scripts - directory for service scripts.

For simplicity and convenience, I decided to base my solution on the library @ngneat-transloco, which is common for the two repository libraries.
It provides a unified translation file and a service with which they interact.

In the case of publishing UI libraries, this library will also be published and will serve as a peer dependency.

This solution is more suitable for large monorepositories where translations are managed through a core library with assets/i18n. Nothing prevents my solution from being applied to ngx-translate, where there is a mechanism for service inheritance or separation.

1. Library i18n-wrapper

This library will contain two directories:

transloco - a directory for transloco wrappers
types - common types for typing the translation file.

Typing tokens for translation

We are accustomed to specifying a translation token as a string in the form of keys separated by a dot. Example: lib.scope.module.component.somekey.

I wanted to maintain this approach and create a type that calculates all possible keys from our unified translation file.

I decided to base such a type on the recursive type presented in an article by @bytefer.

Unlike the universal version in the article, I will trim this recursive type for our solution, so it provides only the final paths through a dot to the primitive.



type TAddPrefix<Prefix extends string, Key extends string> = [Prefix] extends [never]
 ? `${Key}`
 : `${Prefix}.${Key}`;


export type TObjectKeyPaths<T extends Record<string, any>, Prefix extends string = never> = {
 [P in string & keyof T]: T[P] extends object
   ? TObjectKeyPaths<T[P], TAddPrefix<Prefix, P>>
   : T[P] extends string
     ? TAddPrefix<Prefix, P>
     : never;
}[string & keyof T];

Having a recursive type to retrieve translation paths, all that's left for us to do is to create a type that transforms the readonly type from i18n.db.ts to a key map for each locale, ensuring synchronization between languages.



export type TTranslatePath<
 DB extends object,
 Langs extends keyof DB = keyof DB
> = TObjectKeyPaths<DB[Langs]>

With these two types, we've obtained the CORE part of our typing, which addresses 80% of the issues from the posed problem, which can already be applied to different parts of the project, not just to localization.

Only 20% remains - a typed wrapper for transloco.

There will be only three wrappers, and all of them are abstract:

AbstractTranslocoConfigService - a service regulating the list of available languages when providing settings for TRANSOLO_CONFIG. It also implements the TranslocoLoader interface to load our translation file.
AbstractTranslocoService - a service wrapper over TranslocoService, which offers a similar list of methods from TranslocoService, but at the same time narrows down the types of available languages and keys to those available from i18n.db.ts.
AbstractTranslocoComponent - one of the entities that will inject translations into the template based on the provided token (similar to pipe and directive).

AbstractTranslocoConfigService

As I mentioned earlier, it is necessary to provide functions for the TRANSLOCO_CONFIG and TRANSLOCO_LOADER tokens when values are delivered through a factory.

This service is straightforward and will accept one generic from the type of our translation file for typing the available list of languages.

Since we know the available list of languages, and we get the default language in the constructor, for the method providing the config, we can exclude defaultLang, availableLangs, and fallbackLang, leaving settings for transloco.



export type TTypedTranslocoConfig = Partial<Omit<TranslocoConfig, 'defaultLang' | 'availableLangs' | 'fallbackLang'>>;

Result



export abstract class AbstractTranslocoConfigService<
   i18nDb extends Record<string, Translation>,
   Lang extends keyof i18nDb = keyof i18nDb,
> implements TranslocoLoader {
   public readonly AVAILABLE_LANGS: Lang[]


   protected constructor(
       public readonly DB: i18nDb,
       public readonly DEFAULT_LANG: Lang,
   ) {
       this.AVAILABLE_LANGS = Array.from(
           new Set<Lang>([
               DEFAULT_LANG,
               ...Object.keys(DB) as Lang[],
           ]),
       );
   }


   public getProvidedConfig(config: TTypedTranslocoConfig): TranslocoConfig {
       const patchedConfig: Partial<TranslocoConfig> = {
           ...config,
           defaultLang: this.initializeDefaultLanguage() as string,
           availableLangs: this.AVAILABLE_LANGS as string[],
           fallbackLang: this.DEFAULT_LANG as string
       }


       return translocoConfig(patchedConfig);
   }


   private initializeDefaultLanguage(): Lang {
       const browserLanguage = getBrowserLang() as Lang | undefined;


       if (!browserLanguage) {
           return this.DEFAULT_LANG
       }


       return this.isAvailableLang(browserLanguage) ? browserLanguage : this.DEFAULT_LANG;
   }




   public isAvailableLang(lang: Lang | string): lang is Lang {
       return this.AVAILABLE_LANGS.includes(lang as Lang)
   }


   public getTranslation(lang: string): Observable<Translation> {
       return of(this.DB[lang])
   }
}

AbstractTranslocoService

This service doesn't contain any particular logic and serves as a typed intermediary between entities wanting to use the TranslocoService.

For simplicity and to minimize code, I've only added methods for language management.

The only distinctive feature of this service from the native TranslocoService is the filtering of languages based on the AbstractTranslocoConfigService to avoid setting an unavailable language.



export abstract class AbstractTranslocoService<
   i18nDb extends Record<string, Translation>,
   Lang extends keyof i18nDb = keyof i18nDb,
> {


   protected constructor(
       protected readonly translocoService: TranslocoService,
       protected readonly translocoConfigService: AbstractTranslocoConfigService<i18nDb, Lang>
   ) {
   }


   public getActiveLang(): Lang {
       return this.translocoService.getActiveLang() as Lang;
   }


   public setActiveLang(candidate: Lang): void {
       this.translocoService.setActiveLang(this.checkLanguage(candidate) as string);
   }


   public getDefaultLang(): Lang {
       return this.translocoService.getDefaultLang() as Lang;
   }


   public setDefaultLang(candidate: Lang): void {
       this.translocoService.setDefaultLang(this.checkLanguage(candidate) as string);
   }


   public getAvailableLangs(): Lang[] {
       return this.translocoService.getAvailableLangs() as Lang[];
   }


   private checkLanguage(language: Lang): Lang {


       if (this.translocoConfigService.isAvailableLang(language)) {
           return language as Lang
       }


       const browserLanguage: string | undefined = getBrowserLang();
       if (browserLanguage && this.translocoConfigService.isAvailableLang(browserLanguage)) {
           return browserLanguage;
       }


       return this.getActiveLang() || this.translocoConfigService.DEFAULT_LANG;
   }
}

AbstractTranslocoComponent

I've chosen to implement this through a component, and this choice is deliberate for several reasons:

It allows us not to declare functions in the template, which could be restricted by eslint rules.
There's an option to detach the component from the component tree for optimization when switching languages.
For QA purposes, there's the possibility to bind our token to an element using HostBinding, allowing for identification of which token is being used in a particular location.
Auto-suggestions for available tokens are provided.

Cons:

There's a need to specify the complete key from the translation file.
It's impossible to pass the value from one component to others that accept text only in the string format and don't allow customization via <ng-content> or TemplateRef.

Fortunately, these drawbacks are addressed by creating wrappers for the translocoPipe and translocoDirective.

To reduce coupling, I will introduce an interface named ISelectTranslateService, which will regulate the service implementation for translations based on parameters.



export interface ISelectTranslateService<
   i18nDB extends Record<string, Translation>,
   Lang extends keyof i18nDB = keyof i18nDB> {
   selectTranslate$: (
       path: TTranslatePath<i18nDB>,
       params?: HashMap,
       lang?: Lang
   ) => Observable<string>
}

Result



@Directive()
export abstract class AbstractTranslocoComponent<
 i18nDb extends Record<string, Translation>, Lang extends keyof i18nDb = keyof i18nDb,
> implements OnChanges {
 private readonly update$: ReplaySubject<void> = new ReplaySubject<void>(1);


 public translation$: Observable<string> = this.update$.asObservable().pipe(
     switchMap(() => this.getCurrentTranslation$())
 );


 @Input()
 public key!: TTranslatePath<i18nDb>


 @Input()
 public params?: HashMap;


 @Input()
 public lang?: Lang;


 protected constructor(
   protected service: ISelectTranslateService<i18nDb, Lang>
 ) {
 }


 public ngOnChanges(): void {
   this.update();
 }


 public update(): void {
   this.update$.next();
 }


 private getCurrentTranslation$(): Observable<string> {
   return this.service.selectTranslate$(
       // @ts-expect-error: not be infinite
       this.key,
       this.params,
       this.lang
   )
 }
}

(advanced implementation with detach and HostBinding)

2. Library typed-transloco

Unified Translation Database

Firstly, I'd like to move away from the usual practice of placing translations under each locale in json to a single ts file.

assets/i18n/en.json



{
 "actions": {
   "back": "Back",
   "confirm": "Are you sure?",
   "new": "New"
 },
 "layouts": {
   "about": "About",
   "account": "Account",
   "app_store": "App Store"
 }
}

assets/i18n/de.json



{
 "actions": {
   "back": "Zurück",
   "confirm": "Bist du sicher?",
   "new": "Neu"
 },
 "layouts": {
   "about": "Um",
   "account": "Konto",
   "app_store": "Appstore"
 }
}

It exports a single object with all translations under each locale.

i18n.db.ts



export const TRANSLATE_DB = {
 "de": {
   "actions": {
     "back": "Zurück",
     "confirm": "Bist du sicher?",
     "new": "Neu"
   },
   "layouts": {
     "about": "Um",
     "account": "Konto",
     "app_store": "Appstore"
   }
 },
 "en": {
   "actions": {
     "back": "Back",
     "confirm": "Are you sure?",
     "new": "New"
   },
   "layouts": {
     "about": "About",
     "account": "Account",
     "app_store": "App Store"
   }
 }
};

Essentially, yes, I'm moving away from lazily loaded translations towards synchronous loading and predictable typing.

Certainly, you can import JSON files into TS, but then you'd have to configure tsconfig.json for resolveJsonModule. Also, for personal reasons, I find this approach suboptimal if there's a process for exporting a single translation file from the project.

Typed Entities

With the presence of a single translation file and abstract wrappers, we can implement typed versions for our translations:

TypedTranslocoConfigService ```typescript

@Injectable()
export class TypedTranslocoConfigService extends AbstractTranslocoConfigService {
constructor() {
super(TRANSLATE_DB, 'en');
}
}


- TypedTranslocoService
```typescript


@Injectable()
export class TypedTranslocoService extends AbstractTranslocoService<typeof TRANSLATE_DB>{
   constructor(
       translocoService: TranslocoService,
       typedTranslocoConfigService: TypedTranslocoConfigService
   ) {
       super(translocoService, typedTranslocoConfigService);
   }
}

TypedTranslocoComponent ```typescript

@Component({
selector: 'typed-transloco-component',
standalone: true,
imports: [CommonModule],
template: '{{ translation$ | async }}',
changeDetection: ChangeDetectionStrategy.OnPush,
})
export class TypedTranslocoComponent extends AbstractTranslocoComponent{
constructor(
public typedTranslocoService: TypedTranslocoService
) {
super(typedTranslocoService);
}
}


#### TypedTranslocoModule

It will also be required to declare all the created services and provide the necessary values when we want to use translations.

```typescript


@NgModule({
   imports: [TranslocoModule],
   providers: [TranslocoService]
})
export class TypedTranslocoModule {
   static forRoot(config: TTypedTranslocoConfig = {}): ModuleWithProviders<TypedTranslocoModule> {
       return {
           ngModule: TypedTranslocoModule,
           providers: [
               TypedTranslocoService,
               TypedTranslocoConfigService,
               {
                   provide: TRANSLOCO_LOADER,
                   useExisting: TypedTranslocoConfigService,
               },
               {
                   provide: TRANSLOCO_CONFIG,
                   deps: [TypedTranslocoConfigService],
                   useFactory: (configService: TypedTranslocoConfigService) => {
                       return configService.getProvidedConfig(config)
                   }
               }
           ]
       }
   }
}

3. Integration into UI libraries

The main objective of this article is to demonstrate a solution for typing translations, so the examples for these libraries will be simple and contain minimal logic.

For this purpose, a showcase component was created in each of them.

Both components, conditionally, display a list of available components from the library for the user, similar to the storybook.

I only interact with the component template and will create one element that supports typed localization for now.

Since we passed the computed type from TRANSLATE_DB when creating our component, the code editor can already suggest to us which available tokens we have for translation.

This also works for the list of available languages.

When attempting to specify an incorrect token, the editor will highlight a warning indicating that we have specified the key incorrectly. We will deliberately leave this issue uncorrected.

Result

ui-actions library



<button>
   <typed-transloco-component key="actions.back"></typed-transloco-component>
</button>


<button>
   <typed-transloco-component key="actions.confirm"></typed-transloco-component>
</button>


<button>
   <typed-transloco-component key="actions.new-wrong"></typed-transloco-component>
</button>

ui-layouts library



<button>
   <typed-transloco-component key="layouts.app_store"></typed-transloco-component>
</button>


<button>
   <typed-transloco-component key="layouts.account"></typed-transloco-component>
</button>


<button>
   <typed-transloco-component key="layouts.about"></typed-transloco-component>
</button>

Using libraries in an application

You can't showcase the localization in libraries without using a demo application. It will be small and contain minimal code.

Displays our two components from the libraries, as well as switches the language through the TypedTranslocoService.



@Component({
 selector: 'app-root',
 template: `
   <lib-actions-showcase></lib-actions-showcase>
   <lib-layouts-showcase></lib-layouts-showcase>
   <div>
     <button (click)="onChangeLang('en')">EN</button>
     <button (click)="onChangeLang('de')">DE</button>
   </div>
 `,
 styles: [`:host {display: flex; flex-direction: column; gap: 8px}`]
})
export class AppComponent {
 constructor(
     private typedTranslocoService: TypedTranslocoService
 ) {}


 public onChangeLang($event: any): void {
   console.log('lang: ', $event)
   this.typedTranslocoService.setActiveLang($event)
 }
}

In addition to importing the library components, the localization module is imported with forRoot to register all necessary services.

When trying to launch our application, we encounter an error 🔥.

This is the result we've been striving for throughout the entire article - we catch errors from incorrect tokens and ensure typing.

Let's fix the error 🚀

And let's rebuild the application. It successfully compiled 🎉🎉🎉, and now we can switch to the browser to see the final result.

And our localization works.

Final result

Repository

In the next article, I'll discuss how to eliminate the need to synchronize keys between translation maps across locales by implementing "file replacement" for libraries. I'll also showcase a fully automated system for localizing an application based on a single translation map for the desired locales through CI.

About Noda

Noda is a global, multi-currency open banking solution for seamless business transactions. It currently operates with 1,650 banks across 28 countries, encompassing 283 bank brands with over 30,000 branches.

Noda enables merchants to receive direct bank payments from eCustomers via Open Banking as an alternative to cards. Merchants can implement Open Banking payments quickly via Noda API, making use of their intuitive UX and lower fees.

How to Boost SEO for Startups: 4 SEO Tips to Grow Your Business

Noda — Mon, 25 Sep 2023 10:20:56 +0000

Life may seem tough for startups, especially in the realm of Social Engine Optimisation (SEO). With our brand-new websites and consequently low domain authority, it proves more difficult to get to the top of Google’s hierarchy. That’s why startups have to create a complete on-page/off-page SEO strategy and identify the key strengths of their products and services to focus on.

Being a startup ourselves, at Noda we have increased our Domain Rating by 200% in a few months. We’ve done it using our “white” off-page SEO tactics, detailed analysis of the external sources and growing popularity on the Internet.

Here we’ve gathered some of the key tips and valuable insights into the best SEO practises and strategies as a new business.

Primary SEO Concerns for Startups

Limited Budget and Resources

Unlike established companies, startups often operate on a shoestring budget. Allocating a sizable chunk to SEO can be a challenge. They often grapple with the decision of whether to invest in paid search marketing (like Google Ads) or organic SEO or strike a balance between the two.

Immediate Results vs. Long-Term Strategy

Startups, especially those with investor backing, are under pressure to show growth and traction. SEO typically offers long-term benefits, and startups are often concerned about the duration it will take to see tangible results.

Measuring ROI

Understanding which strategies are working and offering a good return on investment (ROI) is crucial. Startups often struggle to set up the right metrics and KPIs to measure their SEO success.

New website challenges

Usually, startup websites are new and have low parameters due to their youth. It takes time to raise domain authority and ratings with off-page SEO. After creating a content strategy, it may take a while to start ranking for queries, find out what type of content performs better and why, attract organic traffic, and gain the trust of Google’s algorithms.

Budget

The budget can vary, depending on how much the company is willing to invest in SEO. That’s why teams must find the best way to spend this budget with visible results. For example, on link-building and high-quality content.

Tip #1: Determine Your Budget

Before allocating any funds, startups need to determine their immediate SEO needs. Is it a site overhaul for SEO optimisation? Do they need more content? Or is link-building the focus? By prioritising their needs, startups can allocate funds more effectively.

Some SEO expenses are fixed, like monthly subscriptions to SEO tools or retainer fees for agencies. Other costs, like content creation or link-building campaigns, can vary. It's essential to categorise these costs to avoid overshooting the budget.

If content creation is outsourced, startups need to decide on the frequency (e.g., weekly, bi-weekly) and type of content (blog posts, videos, infographics). Costs can vary widely based on these factors.

Budgeting decisions should be tied closely to expected ROI. If a particular strategy or channel yields good returns, it might make sense to allocate more funds there, even if it wasn't part of the initial plan.

Tip #2: Conduct Competitor Analysis

Competitor analysis usually starts by evaluating the website metrics like Domain Rating/Domain Authority, traffic, top organic keywords, top pages, website structure, visual elements, and more. Based on at least 5-10 biggest competitors SEO teams can form a clear picture of their company’s niche.

Start by listing companies that offer similar products or services. Not all direct business competitors will be SEO competitors, and vice versa. Tools like SEMrush or Ahrefs can help identify websites that rank for similar keywords.

Examine which keywords competitors are targeting and how they rank. Look at both short-tail and long-tail keywords. This can reveal gaps in your keyword strategy and present opportunities for targeting less competitive, high-ROI terms.

Examine the quality and quantity of backlinks pointing to competitor websites. Tools like Moz or Ahrefs can help with this task. A robust backlink profile can significantly boost domain authority. By understanding where competitors are getting their links, startups can identify potential backlink opportunities.

For startups targeting local audiences, it's crucial to analyse competitors' local SEO strategies. This includes examining their Google My Business listings, local backlinks, reviews, and local keyword rankings.

Tip #3: Prioritise UX

Since Google started using basic UX metrics in the ranking, life has become somewhat harder. Generally speaking, badly designed sites had to be cleaned up, for example, by enlarging clickable areas and providing adequate contrast.

Although for well-designed sites it’s business as usual, the page load time metric hit everybody. Only very specialised businesses can still be hosted traditionally, the rest (those with competition) had to invest in geolocalised hosting to make their website faster, regardless of the country.

Tip #4: Advanced Keyword Research

Keyword research is one of the most important tasks when it comes to SEO strategy and implementation.
Startups can use special SEO tools like Ahrefs and KWFinder by Mangools. They can analyse their competitors’ pages among top Google results.

Paying attention to what keywords the competitors are ranking for is important, as well as noting phrase variations in copy. Other tactics include evaluating LSI (Latent Semantic Indexing), looking for words repeated on different pages, and counting approximate text length.

Finding Fast-Ranking Keywords

Long-tail keywords, typically three or more words in length, tend to have lower search volumes but also less competition. This makes them easier to rank for. They often have a higher conversion rate too, since they're more specific.

Tools like Ubersuggest, Ahrefs, SEMrush, and Google Keyword Planner can be invaluable. They allow you to find keyword variations, assess competition levels, and gauge search volumes.

Keyword Difficulty

Some keyword research tools, like Ahrefs, provide a 'Keyword Difficulty' score. This score gives an estimate of how hard it would be to rank in the top 10 search results for that keyword. Ideally, startups should target keywords with lower difficulty scores.

See which keywords your competitors rank for, especially those not in the top spots but on the first page. These can be potential targets if you believe you can produce better content or a more relevant offer.

Some keywords might offer quick wins in terms of rankings but not drive valuable traffic. Ensure the keywords you prioritise align with your business goals and user needs.
Final Thoughts

For startups, navigating the SEO landscape may seem overwhelming, especially with limited resources and the pressure for immediate results. However, by adopting a strategic approach, startups can effectively harness the power of SEO to their advantage.

It all starts with establishing clear budgets and conducting thorough competitor analysis. Prioritisng user experience is key, as well as utilising advanced keyword research techniques.

Taking inspiration from Noda's growth, it's evident that a well-executed SEO strategy, combined with a deep understanding of one's niche and target audience, can lead to substantial returns and lay the groundwork for long-term success in the digital realm.