Full-Stack Developer playing with clouds, LAMP, Symfony, JavaScript. Currently working as a Salesforce developer as part of the Taylor & Hart team.
Kik Minev
01.

Hey there, I'm Kik Minev - web developer playing with clouds, LAMP, Symfony, JavaScript, Salesforce Apex. Currently working as a Salesforce developer as part of the Taylor & Hart team.

Why Salesforce? Pivoted to Salesforce when my colleagues needed a quick and efficient way to optimize business processes, sales and even manufacturing processes. That’s how I stepped into the Salesforce world, though most of my career has been focused on web with PHP. Strong love for the Symfony framework.

02.

My experience

Taylor & Hart - Salesforce and Symfony developer

Currently working as a Salesforce developer at Taylor & Hart where I help with accelerating business processes in sales and manufacturing. I spend my day mostly writing Apex code and lightning components in Salesforce or PHP/Symfony for web features.

Oxxy - CTO

As part of Oxxy I was leading the team as a CTO. We started and shipped a drag and drop website builder that allows small business owners to launch a website without any coding skills. For my tasks I used the Symfony PHP framework, MongoDB, javascript for the web builder and AWS as an ifrastructure.

Webfactory - Web Developer

At Webfactory I spent my days mostly coding with PHP and Javascript. As part of a web agency I worked on various projects for different clients up until I started working on Protect Your Bubble. Really thankful to the colleagues that gave me the chance to work on this project and helped me develop my skills.

Webfactory / Protect Your Bubble - Team Lead

I became responsible for launching the US web site and lead a team of web developers to deliver and support the project. Duties were a bit different as I needed to work in Atlanta and lead the team overseas. Also, working with a Fortune 500 company has it's perks. Thank you all for the warm welcome in Atlanta!

Digitalus - Web Developer

Digitalus was a hosting company from The Netherlands(later aquired by another company). Here we worked with PHP and Javascript.

SiteGround

Epic times! Great start in the web industry.

03.

What I work with?

Back in the days I started coding websites from scratch using PHP and some custom frameworks. Throughout time I worked with ancient frameworks like CakePHP, Zend and others. Nowadays I mostly work with Symfony. Trying to keep an eye on the Javascript world as well.

PHP
Back in time I started with PHP from around version 4. Usually with Apache and MySQL. These days we run mostly nginx.
JavaScript
The beginings was vanilla and jQuery. Later I worked with Backbone and Angular. Now I try to keep in touch mostly with the React framework.
Symfony
I love how robost Symfony is. The initial steep learning curve is paying off with the projects. During the years I've worked with Symfony for SaaS products, CMS and eCommerce systems.
AWS
My experience with the cloud is in AWS where I mostly use EC2 and S3. I also have some experience with RDS for PostgreSQL. During the years I used EC2 to scale Symfony web projects and MongoDB cluster databases.
Git
Git is what I use for version control. Checkout my GitHub. I use Gitflow in my day to day work.
Docker
For personnal projects I will use Docker to maintain my developement environment. In some companies we also worked remotely, in the cloud. In other companies even with k9s on localhost. Depends on the company;)
Salesforce Apex
In Salesforce I usually work with Apex code to develop new features. It shares the Java syntax and object-oriented features, but it's limited by the Salesforce environment.
Ligning Components
Not very often I develop lighning components to extend the Salesforce functionality.
PhpStorm
Though I started with Notepad, moved to Notepad++, Vim, Eclipse, these days I work with PhpStorm and IntelliJ with Illuninated Cloud for Salesforce development.

Creating automatic Salesforce backup data export in AWS

As we know, backup solutions for Salesforce are incredibly expensive. At the same time, the built-in Salesforce data export is irritating and not really a working solution. When you start an export using the Salesforce tool, the download links expire within 48 hours, and the interface doesn’t allow you to download them all at once. This forces people to click on each download one by one and wait for hours, only to end up with a download that might not even complete successfully. All this makes data export an incredibly irritating process, and it seems that Salesforce has no plans to fix it, as they haven’t done so for years.

Fortunately, there is an easy-to-implement alternative using AWS solutions.

Automatic Salesforce data export with AWS AppFlow and S3

To address the problem above, I created a quick automation using Amazon’s AppFlow product. In short, it allows you to integrate Salesforce (or other SaaS products) and securely transfer data between Salesforce and AWS.

The connection is really straightforward, and once you set it up, you can tell AppFlow which Salesforce objects you want to transfer to AWS. In the next configuration step, you tell AppFlow to store your data in a private S3 bucket, obviously following strict security measures.

All these steps are done through a convenient UI, and it doesn’t take long before your data starts flowing into S3.

As an additional benefit, you can use the S3 Parquet file format, which stores data much more efficiently than CSV. The storage space required can be 3 to 10 times smaller than that of standard CSV files exported by Salesforce Data Export.

Another side benefit of this solution is that you can later query your Parquet data directly from S3 using Amazon Athena. In case you ever need such a perk…

Pricing

For a couple of GB, e.g. 10 GB, I expect the bill to be a couple of dollars per month. This can be further improved by using AWS Glacier for old backups. Glacier is another AWS solution that allows you to store files that you rarely need. They take longer to retrieve but are cheaper to store.

You should also know that AWS AppFlow charges based on the number of flows. For example, if you have 100 Salesforce objects, you will need to set up 100 flows to sync them automatically. This is an automated process, so don’t worry about having to click through all of them manually.

Considerations

1. Security: Obviously, the main consideration when building this is security. You don’t want your data exposed somewhere on the internet, sitting in a CSV file, as even Fortune 500 companies have made this mistake in the past. Therefore, you should implement all the security measures required by AWS and S3.

2. Flow Connections: When you set up the connection from AppFlow to Salesforce, you essentially tell AppFlow which objects to subscribe to and start syncing to S3. The inconvenience here is that any new custom fields you add to the objects will not appear automatically in AppFlow, so you should build additional automation to handle this.

3. Using the data: Restoring or using the data is no different from working with the old-school CSV data export provided by Salesforce, which allows you to download CSV files. Essentially, the Parquet files can easily be converted into CSV files, which you can download and use just like the files exported directly from Salesforce.

Leave a Reply

Your email address will not be published. Required fields are marked *